MASTER THESIS

TITLE: Design and integration of a multipurpose on board computer for nanosate-

llites with Software Defined Radio communications

DEGREE: Master in Aerospace Science and Technology (MAST)

AUTHOR: Carles Sierra Roig

DIRECTOR: Juan Jose Ramos Castro

DATE: 19 de setembre de 2019

 Title : Design and integration of a multipurpose on board computer for nanosatellites with
Software Defined Radio communications
Authors: Carles Sierra Roig
Advisor: Juan Jose Ramos Castro
Date: September 19, 2019

Overview

This document describes and summarizes the design process carried out by Carles Sierra
and its colleagues at Intitut d’Estudis Espacials de Catalunya (IEEC) for the C3SatP project
in the context of his Final Master Thesis for the Universitat Politecnica de Catalunya (UPC).
The document is focused on both high level design (system design) as well as low level
hardware design (mainly electronics, but mechanical and thermal as well) of the C3SatP
nano-satellite computer: a modular, versatile and powerful digital system that will control,
gather, process and transmit satellite data. The progress here explained will cover the
work done mainly by the author, but also by some of its collaborators in the same project
due to its multidisciplinary team, such as: System design, Power Supply design, Inter-
connection schemes, Printed Circuit Board (PCB) design, Project Outreach and System
Structures. It excludes several designs in which the Author is not actively involved in, such
as the Software Defined Radio (SDR) PCB, main On-Board Computer (OBC) components,
embedded software design, etc.
Keywords: C3SatP, SDR, Nano-satellite, CubeSat, MPSoC, FPGA, Zynq Ultrascale+,
DDR4, PMIC, Space Electronics, Space Engineering.
Tı́tol: Diseny i integració d’un ordinador d’abord per nanosatèl·lits amd communicacions
Software Defined Radio
Autors: Carles Sierra Roig
Director: Juan Jose Ramos Castro
Data: 19 de setembre de 2019

Resum

Aquest document descriu i resumeix el procés de disseny realitzat per Carles Sierra i els
seus col·laboradors de l’Institut d’Estudis Espacials de Catalunya (IEEC) per al projecte
C3 SatP en el context de la seva Tesi final de màster per a la UPC.
El document es centra tant en el disseny d’alt nivell (disseny del sistema) com en el disseny
de baix nivell (principalment electrònica, però també mecànica i tèrmica) de l’ordinador per
a nano-satèl·lits C3 SatP: un potent, modular i versàtil sistema digital que controlarà, reu-
nirà, processarà i transmetrà dades de satèl·lit. Els avenços aquı́ explicats abarcaran els
treballs realitzats principalment per l’autor, però també per alguns dels seus col·laboradors
degut al caire multidisciplinari de l’equip, com ara: Disseny del sistema, disseny de l’etapa
d’alimentació, esquemes d’interconnexió, disseny de plaques de circuit imprès, disseny
d’estructures mecàniques i campanyes de divulgació. Exclou diversos dissenys en els
quals l’autor no hi participa activament, com ara la placa de la “Software Defined Radio”,
components de l’ordinador d’abord principals, disseny de sfotware, etc. newline
Paraules clau: C3 SatP, SDR, Nano-satèl·lit, CubeSat, MPSoC, FPGA, Zynq Ultrascale +,
DDR4, PMIC, Electrònica espacial, Enginyeria espacial, IEEC, ICE-CSIC, ICC-UB, UPC.
Design and integration of a MP-OBC with SDR for nano-satellites 1

Contents
1 Introduction 7
1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Scope and Reach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Background 11
2.1 IEEC: Institut d’Estudis Espacials de Catalunya . . . . . . . . . . . . . . . 11
2.2 C3 SatP: the IEEC CubeSat computer concept . . . . . . . . . . . . . . . . 11
2.3 Team Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 C3 SatP System Design 14

3.1 On-Board Data Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 On-Board Computer (a.k.a.Motherboard) . . . . . . . . . . . . . . . . . . 18
3.3 Software Defined Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 On-Board Data Handling design 22

4.1 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4 Prototype and Test . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.5 Results and future work . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Layout design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.3 Results and future work . . . . . . . . . . . . . . . . . . . . . . . 40

5 System interfaces 42
5.1 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Internal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 SDR-OBC connection . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 OBCbotom-OBCtop connection . . . . . . . . . . . . . . . . . . . 45
5.2.3 OBC-OBDH connection . . . . . . . . . . . . . . . . . . . . . . . . 46

6 System structures 48
6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Mechanical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Results and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Outreach 53
7.1 Second Barcelona Technoweek Week . . . . . . . . . . . . . . . . . . . . 53
7.2 Sonar+D workshop and MakerFaire . . . . . . . . . . . . . . . . . . . . . 53
7.3 Second Open Source CubeSat Workshop . . . . . . . . . . . . . . . . . . 57
2 Design and integration of a MP-OBC with SDR for nano-satellites

8 Conclusions 59
8.1 Thesis objectives achieved . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.2 Thesis objectives not reached . . . . . . . . . . . . . . . . . . . . . . . . 60
8.3 Project goals status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Appendix 65

A Complete Chronograph 65

B OBC and SDR boards mechanical drawings 69

C Complete OBDH stack-up design 72

D Open Source CubeSat Workshop poster 73

E Complete OBDH schematic 75

F OBC stand-alone version datasheet 94

Design and integration of a MP-OBC with SDR for nano-satellites 3

List of Figures
1 C3SatP satellite block diagram. . . . . . . . . . . . . . . . . . . . . . . . 12
2 C3 SatP computer bloc diagram of its main subsystems, digital buses and
external connectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 First version of the OBDH subsystem (left) and current one (right). . . . . . 16
4 First version of the motherboard a.k.a OBC. . . . . . . . . . . . . . . . . . 18
5 Current version of the OBC (left) and its Stand-alone version (Right). . . . . 20
6 SDR board ready to be tested. . . . . . . . . . . . . . . . . . . . . . . . . 21
7 Complete power distribution architecture for Zynq Ultrascale+. . . . . . . . 23
8 Table depicting the trade-off analysis of different solutions regarding regula-
tors architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9 Table depicting the trade-off analysis of different PMIC solutions . . . . . . 25
10 Buck converter model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11 Picture of the mounted PMIC prototype PCB . . . . . . . . . . . . . . . . 29
12 Table summarizing the design parameters for each of the MPSoC rails. Note
that in the schematic of Figure 13, R3 2V 5 DDR V PP corresponds to rail
R6 in this table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13 Schematic of the PMIC final implementation developed with Cadence Alle-
gro Design SW. Note that here R3 2V 5 DDR V PP corresponds to rail R6
in the table of Figure 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14 Images of the main OBDH components. From left ro right: DDR4, MPSoC
and PMIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15 Typical micro-strip’s sections used for Zo calculations (left, courtesy of Man-
taro [33]) and layers from OBDH PCB (right). Dielectric layers between them
have been omitted for convenience. . . . . . . . . . . . . . . . . . . . . . 35
16 OBDH power stage implemented with Cadence Allegro PCB Designer. . . . 36
17 OBDH power planes in Cadence Allegro. from top to botom and left to right:
Top and bottom planes, main power plane (+5V input voltage as well as
R1 and R2 rails), second plane (R4 and R5 rails) and third plane (DDR4
termination voltage plus R3 and R6 rails). . . . . . . . . . . . . . . . . . . 37
18 Zynq Ultrascale+ 4EG routing plan . . . . . . . . . . . . . . . . . . . . . . 39
19 Zynq Ultrascale+ 4EG pin distribution (left) and DDR4 digital buses (right). . 40
20 Image of Cadence Allegro PCB designer of the Zynq footprint (blue circles)
with the vias required by the manufacturer (big ones) and the ones currently
implemented (small ones). . . . . . . . . . . . . . . . . . . . . . . . . . . 41
21 CubeSat Structure with its spacers for PCBs (left) and first C3 SatP CAD
version with the holes to interface any commercial structure . . . . . . . . 42
22 From left to right: (a) PC104 at the lower-right corner of the PCB, (b) Molex
PicoLock connector, (c) Amphenol SMPM connector, (d) Molex PicoBlade
connector and (e) Samtec LSHM connector. . . . . . . . . . . . . . . . . . 43
23 C3SatP boards with their reference (left) and OBC blueprint (right). Frame’s
color represents subsystem connection: Blue ones connected to OBDH, red
ones to OBC and yellow ones to the SDR. . . . . . . . . . . . . . . . . . . 43
24 SDR PLA 3D printed structural elements with an Ag+Cu coating. . . . . . . 50
25 C3SatP computer explosion with its aluminum boxes. . . . . . . . . . . . . 51
4 Design and integration of a MP-OBC with SDR for nano-satellites

26 Simplified CAD model (left) used in the thermal simulations of the C3 SatP
computer (right). Courtesy of Manuel Carmona. . . . . . . . . . . . . . . . 52
27 MATE mission renderings . . . . . . . . . . . . . . . . . . . . . . . . . . 53
28 Pictures of the Sonar+D workshop. . . . . . . . . . . . . . . . . . . . . . 54
29 Pictures of the CubeSat designed for the Sonar+D workshop . . . . . . . . 55
30 Pictures of the “launched” CubeSat (left) and the telemetry received from its
camera and sensors (right). . . . . . . . . . . . . . . . . . . . . . . . . . 56
31 Pictures of the Maker Faire stand. . . . . . . . . . . . . . . . . . . . . . . 57
32 Picture of the OSCW assistants. . . . . . . . . . . . . . . . . . . . . . . . 58
33 OBDH stack-up complete definition. . . . . . . . . . . . . . . . . . . . . . 72
Design and integration of a MP-OBC with SDR for nano-satellites 5

Acronyms
a.k.a also Known as. 18, 25, 34 FRAM Ferroelectric RAM. 19, 20

ADC Analog to Digital Converter. 38

GOMspace Grumpy Old Men Space. 12,
ADCS Attitude Determination and Control 42, 63
System. 7, 12, 19
GPIO General Purpose Input/Output. 15,
ARIEL Atmospheric Remote-sensing In- 16, 22, 28, 29, 31
frared Exoplanet Large-survey . 7, 11,
61, 63
HK HouseKeeping. 19, 22, 23, 31, 40

BGA Ball Grid Array. 16, 21, 29, 32, 33, 36, HW Hardware. 10, 15, 22, 24, 44, 61
39, 41
I/F Interface. 15, 16, 18, 21, 28, 42, 44
CAD Computer Aided Design. 3, 4, 33, 42,
I/O Input-Output. 17, 23
48–50, 52, 55, 56

CAN Controller Area Network. 16, 17, 19 I2C Inter-Integrated Circuit. 16, 17, 28, 29,
40
COTS Component Of The Shelf. 7, 9, 12,
15, 22, 48 IBIS Input/output Buffer Information Speci-
fication. 38
CTE-CRAE Aerospace and Research Cen-
ter. 63 IC Integrated Circuit. 24

ICC Institut de Ciències del Cosmos. 10,

DC Direct Current. 26, 30, 31, 37 11, 13, 33, 49, 50, 53, 63
DC/DC Direct Current to Direct Current. 24 ICE-CSIC Institut de Ciències de l’Espai.
10, 11, 13, 29, 49, 55, 56, 63
DDR4 Double Data Rate 4 SDRAM (Syn-
chronous Dynamic Random Access ICGC Institut Cartogràfic i Geològic de
memory). 3, 16, 17, 23, 32–34, 36– Catalunya. 12
40, 52
IEEC Intitut d’Estudis Espacials de
Catalunya. 7, 9, 11, 12, 53, 54, 59–63
EDAC Error Detection And Correction. 19
IMU Inertial Measurement Unit. 19
EMI Electro-Mangetic Interference. 19, 21,
31, 34, 36, 37, 48–50 ISIS Innovative Solutions In Space. 12, 42,
63
EPS Electronic power System. 7, 12, 25,
57
JTAG Joint Test Action Group. 16, 18, 38
ESR Equivalent Series Resistance. 27

LDO Low DropOut. 24, 25, 28, 31

FEE Front-End Electronics. 15
LEO Low Earth Orbit. 19, 48, 61
FPGA Field-Programmable Gate Array.
13–15, 17, 21–23, 25, 26, 28, 36, LISA Light Interferometer Space Antenna.
38, 59 7, 11, 61, 63
6 Design and integration of a MP-OBC with SDR for nano-satellites

LVDS Low Voltage Differential Signaling. RS-485 Recommended Standard 485. 17,
15–18, 20, 44 18

MCU Micro-Controller Unit. 17, 19, 20 SD Secure Digital. 16, 19, 20

MEMS Micro-Electro-Mechanical Systems. SDR Software Defined Radio. 3, 7, 8, 12–

19 21, 34, 36, 39, 43–46, 48–50, 52, 59–
61, 69
MIO Media Input-Output. 16, 17
SEL Single Event Latch-up. 22, 30
MPSoC Multi-Processor System on Chip.
3, 14–17, 19, 22–41, 45, 48, 50, 52 SEU Single Event Upset. 15, 19, 63

SPI Serial Peripheral Interface. 15, 16

OBC On-Board Computer. 3, 7, 8, 12–21,
SW Software. 3, 7, 13–15, 17, 19, 21, 24,
23, 30, 32–34, 36, 38, 39, 42–46, 49–
28, 29, 32–35, 39, 44, 52, 60, 61, 64
52, 56, 57, 59–61, 69

OBDH On-Board Data Handler. 2–4, 10, TM&TC Telemetry and Telecommand. 15,
12–14, 16–23, 28–36, 38, 43–46, 49– 18–20
52, 59–61, 72, 75
TRL Technology Readiness Level. 7, 15,
OCP Over-Current Protection. 30 61, 62
OTP Over-Temperature Protection. 30
UAB Universitat Autònoma de Barcelona.
OVP Over-Voltage Protection. 30 11

UART Universal Asynchronous Receiver

PCB Printed Circuit Board. 3, 7–10, 13–17,
Transmitter. 16, 18
19, 21–23, 27–29, 31–36, 39, 40, 42–
45, 48–52, 56, 61, 63, 64 UB Universitat de Barcelona. 11, 50, 54,
55
PLL Phase-Locked Loop. 38
ULPI UTMI+ Low Pin Interface. 16
PLM Payload Module. 12, 15, 42
UPC Universitat Politècnica de Catalunya.
PMIC Power management integrated cir- 9–11, 13, 15, 48, 49, 52, 55
cuit. 3, 17, 20, 24, 25, 28–33, 36, 37,
40 USB Universal Serial Bus. 16, 17, 56

UVP Under-Voltage Protection. 30

RAM Random Access memory. 16, 34, 36,
38–40, 52 VIA Vertical Interconnect Access. 45
RF Radio-Frequency. 13, 19, 20, 43 vs. Versus. 24
RGMII Reduced Gigabit Media-Independent
Interface. 16, 18 XPE Xillinx Power Estimator. 22, 25, 28, 30
Design and integration of a MP-OBC with SDR for nano-satellites 7

1 Introduction

We are now living a paradigm shift when it comes to satellite design in which smaller, less
reliable (thus cheaper and faster to design) satellites are better suitable for certain mis-
sions where classical satellites (big, reliable, and design to last) would be used. The main
driver of this shift is the lower cost of launching a nano-satellite into space, between 1 and
2 orders of magnitude lower [1]. Its primary reason is the miniaturization of Component Of
The Shelf (COTS) electronics, which allows greater features at a reduced size and power
consumption. In this scenario, universities and even some companies can afford a trip to
the last frontier to test new components, instruments, perform some experiments and even
offer services [2].

In 1999 the CubeSat standard was created by Professor Jordi Puig-Suari and Professor
Bob Twigg from California Polytechnic State University and Stanford University, respec-
tively. Its name comes from its cubic shape, a 10x10x10 cm structure, better known as
1U with a maximum allowable mass of 1.33 Kg. Several units can be ”attached” to form
a bigger satellite. 1U, 3U and 6U are amongst the most used configurations. One of their
key features is their standardized deployable module, the so called P-pod, a simple en-
closed box with an ejection spring that guarantees no damage to adjacent satellites if the
CubeSat shatters inside during launch. Their use have been exponentially increasing for
the last 7 years and some forecast millions of them added in Earth constellations in the
very near future.

The IEEC also wants to exploit the advantages of this new technology in order to test crit-
ical components and instruments for bigger missions (LISA [3], ARIEL [4], Euclid [5], etc)
and increase their Technology Readiness Level (TRL). Also to have hands-on experience
and access to the market niche where this satellites are most suitable, for example, Earth
Observation missions using constellations of such satellites. To do so, we would focus our
efforts in designing a subsystem taking into account the team expertise, the requirements
of possible collaborators, and the availability of said subsystem in the market (popular
commercial subsystems such as simple OBC, Attitude Determination and Control System
(ADCS), or Electronic power System (EPS) were avoided)

Thanks to this environment, the C3 SatP project was born, with the main objective of de-
signing and manufacturing a powerful and versatile digital system that will control, gather,
process and transmit satellite data.

This document will provide the description of its capabilities as well as the design process
carried out by the author of the thesis Carles sierra and the team he is involved in. De-
tailed information of some parts of the C3 SatP computer will be omitted due to the lack of
involvement by the author (Software Defined Radio (SDR) PCB, main On-Board Computer
(OBC) components, embedded software design, etc.), in order to highlight its contribution
in the other parts.
8 Design and integration of a MP-OBC with SDR for nano-satellites

1.1 Objectives

As the title of this thesis suggests, the main goal of the project is to develop a powerful
and versatile computer for nano-satellites, with an integrated communication system. The
project is being developed by many engineers, hence, we can differentiate the common
objectives of the team (trying to achieve project’s main goal, please see the first list 1.1)
from the specific targets of the author of this thesis (which tries to achieve some of this
common objectives, please see the second list). Project goals are more ambitious and
costly, as they are composed of several “sub-objectives”, which can be pursued by several
engineers working together. In this regard, every engineer in the team has its own agenda,
pursuing his objectives to fulfill one or several team objectives.

Note that some of the project goals were not defined at the beginning of the project, but in
response to the system’s evolution, such as the development of specific PCBs, for exam-
ple. Also, objectives enumerated in the following lists are not ordered by priority. All targets
are considered equally important for the future of the system.

Project Objectives
PO-1 Develop a motherboard with a reliable micro-controller as master of the system.

PO-2 Develop a communications subsystem based on a SDR.

PO-3 Develop a versatile and powerful digital system for in-flight data processing.

PO-4 Define the internal and external mechanical and electrical interfaces of the computer.

PO-5 Develop the required structural elements for the system’s survival in space.

PO-6 Develop a reliable firmware to safely control the system from ground.

PO-7 Develop the software infrastructure to execute in the GNU/Linux operating system
that runs in the data processing system.

PO-8 Secure future fundings with open calls, collaborations and/or partnerships with com-
mercial companies.

PO-9 Advertise our system in Conferences and Workshops of space related topics.

As Carles Sierra is an electronic engineer, most of the objectives here presented are re-
lated to electronics hardware but also to system’s integration design: he helped in the co-
ordination and communication between engineers to define the computer interfaces (elec-
trical, mechanical, thermal, etc.) and search fruitful synergies. Other objectives, such as
mechanical related ones, rises from the need of having a mechanical engineer role in the
team. The author of the thesis took this endeavor thanks on the knowledge acquired in
the Aerospace Science and Technology Master in UPC and started to coordinate several
mechanical engineers of IEEC (see section 2.3) to design computer’s structural elements.
The following specific objectives are defined to fulfill one or several top level objectives,
Design and integration of a MP-OBC with SDR for nano-satellites 9

which are specified as a number between brackets.

Thesis Objectives
TO-1 Participate in the system design decisions (PO-1, 2, 3, 4 and 5).

TO-2 Coordinate and facilitate the communication between team members working on
electronics, mechanics and thermal aspects (PO-1, 2, 3, 4 and 5).

TO-3 Design the power supply for the digital data processor (PO-3).

TO-4 Design the PCB of the digital data processor (PO-3).

TO-5 Define the electrical and mechanical connections between system boards (PO-1, 2,
3 and 4).

TO-6 Coordinate and participate in the development of structural elements for the system
(PO-4 and PO-5).

TO-7 Promote our project by attending to conferences and workshops of relevant topics
(PO-8 and PO-9).

1.2 Motivation

Our main motivation to develop the C3 SatP computer at IEEC is to acquire the know how of
the CubeSat technology and its political and economical environment in order to take the
proper decisions in the near future for the sake of the institute and our team. The CubeSat
community is growing and is the perfect platform to develop new infrastructures in space
as well as new networks on ground at an affordable cost and time. With a powerful and
versatile computer, we can collaborate with other missions and teams to expand this new
paradigm and contribute to increase the access to space for everyone, at a lower cost, the
so called Democratisation of space.

In the other side, my personal motivation to work on this project, apart from my passion for
space and electronics, is the amazing and simple idea that commercial electronics, COTS,
are able to survive the harsh environments of space (with minor precautions). It changes
your mindset completely when designing space satellites: errors are now tolerable. Tech-
nology development can (and will) progress faster as the players can accept higher risks.
Another reason very appealing for me, is the fact that a junior engineer, as myself, can
participate in many missions during its career, posing more opportunities to learn from fail-
ures than in the classical approach, in which a satellite mission would last between 10 and
20 years (from conception, design, test, launch, operations to decommissioning).
10 Design and integration of a MP-OBC with SDR for nano-satellites

1.3 Scope and Reach

This document is focused on the development of the C3 SatP computer (from its conception
to its current state), with special attention to the author’s contributions so far. The scope
of the document is to put in evidence the different level of design the author has been
involved in.

The document is intended to be distributed only to the UPC reviewers and the authorized
personnel.

1.4 Structure of the document

The structure of this document is as follows. In section 2, the context of this Final Master
Thesis is explained. It contains information regarding the institutions in which the project
has been developed (ICE-CSIC, ICC and cte-crae), a summary of the computer system
conception and the team behind the project. Section 3 describes in more detail the evo-
lution from the first concept to the current version of the system, from a high-level design
perspective. Next sections explain the different contributions to its HW design, the author
of the thesis, Carles Sierra, has been involved in: power supply design (4.1), the OBDH’s
PCB design (4.2) and its integration with the rest of the system (5), the structural elements
design supervision (6) and the outreach campaigns and conferences attended (7). Results
of this contributions are explained in their respective sections. Finally, the overall conclu-
sions of this Master thesis are showed in section 8, with details of achieved objectives, the
reasons of the non reached ones, as well as future work and project previsions.

The appendix provides further information regarding the project chronology (A), Mechan-
ical drawings of the developed boards (B), the stackup (C) and schematics (E) of obdh
electronic design as well as other relevant documentation contributions during the project,
such as the OSCW poster(D) and the obc datasheet (F)
Design and integration of a MP-OBC with SDR for nano-satellites 11

2 Background

This section presents the context of the project and how it was conceived. It shows the
multi-disciplinary team of experts behind its design, and their associated institutions that
lay under the coordination of the IEEC.

2.1 IEEC: Institut d’Estudis Espacials de Catalunya

From its webpage [6]: The IEEC is a research institute that studies all areas of space and
space sciences, including astrophysics, cosmology, planetary science, Earth observation,
and space engineering. Its mission is to push the frontiers of space research from the
scientific and technological domains for the ultimate benefit of society:

• Promote astronomical and space research

• Become an internationally recognized center in order to attract talent and foster
collaborations both locally and worldwide

• Be an efficient agent of knowledge, innovation and technology transfer in its field

• Carry out science awareness to society by communicating scientific culture
The IEEC ranks among the best international research centers, producing a large number
of high-impact publications and leading key world-class projects (LISA [3], ARIEL [4], etc).
It was established in February 1996 as a private, non–profit foundation to foster space
R&D in Catalonia, and it comprises several Research Units, listed hereunder.

• Institute of Cosmos Sciences (ICC) at UB [7]

• Center of Space Studies and Research (CEREs) at UAB [8]
• Research center in Aerospace Sciences and Technologies (CTE-CRAE) at UPC [9]
• Institute of Space Sciences (ICE-CSIC) at UAB [10]
• Nano-Satellites Laboratory (NanoSat Lab) at UPC [11]
The project presented in this thesis has been coordinated by the IEEC, with the participa-
tion of several engineers from its institutions (see section 2.3). In this regard, the author of
the thesis developed its designs mainly at the ICE-CSIC facilities, but also in ICC laborato-
ries. Progress meetings were held in the IEEC headquarters in the Nexus building of the
UPC every two weeks to report the status of the different designs and address any issues
encountered.

2.2 C3 SatP: the IEEC CubeSat computer concept

The experience gained over the last 5 years in the manufacturing of nano-satelites based
on commercial components and dedicated to research projects in EO (from the NanoSat
12 Design and integration of a MP-OBC with SDR for nano-satellites

Lab), as well as the hardware and software experience from the embarked systems on
different ESA missions, led to the creation of a strategic activity within the IEEC in order
to create an in-house system for nano-satellites with a higher level of performance and
reliability than what can be found in the market. This initiative received financing from the
Catalan government through the Knowledge Industry program in the “Product” modality,
aimed at achieving solutions with low TRL to reach the productive sector.

The discussion evolved into a more practical approach whether or not the IEEC should
start designing a CubeSat bus subsystem (main typical subsystems of any satellite such
as OBC, EPS, ADCS, etc.) or focus on a Payload Module (PLM) instrument for our scien-
tists. Several research institutions from Catalonia have been reached to discuss a possi-
ble collaboration to develop a prototype. The Institut Cartogràfic i Geològic de Catalunya
(ICGC) was one of the firsts, with already a draft on how to use nano-satellites to study
soil’s humidity of Catalonia. The team was then conformed and started to doodle a system
level design of a CubeSat, in order to leverage our capabilities with their requirements and
the commercial options. We searched the CubeSat COTS available from companies like
ISIS [12], GOMspace [13], Pumpkin Space Systems [14] or the CubeSat Shop [15]. The
result can be seen in Figure 1.

It was clear by then that the return we would get from developing a bus subsystem would be
very low since the commercial ones have a very competitive prices. This, together with the
fact that the IEEC is a scientific research institution, and tacking into account the team’s
expertise, we decided to develop a versatile computer system for scientific instruments
that could also be used as main OBC, the C3 SatP computer. It would integrate in less
than 1/2U, a master OBC, a powerfull OBDH and two radio transceivers (one based on
a SDR). More information regarding the design process carried out from scratch up to its
current version, can be found in section 3.

Figure 1: C3SatP satellite block diagram.

Design and integration of a MP-OBC with SDR for nano-satellites 13

2.3 Team Members

This section show the people involved in the project and their contribution (apart from
the common contribution in the development of the high-level design of the c3 SatP com-
puter).

• Carles Sierra Roig (ICE-CSIC): Author of the thesis. In charge of electronics, aero-
nautics and Integration. Agustı́ Carrillo’s final degree thesis supervisor, who de-
signed the computer structural elements.

• Juan José Ramos Castro (UPC): Principal Investigator of the project, electronic
engineer and space systems advisor. In charge of the overall system design and the
project management, scheduling and budget.

• Josep Colomé Ferrer (ICE-CSIC): Project management and networking

• José Marı́a Gomez Cama (ICC): Project management and electronic engineer and
advisor.

• Alberto Garcia Rigo (ICE-CSIC): Networking and outreach.

• Jordi Portell de Mora (ICC): Networking and software engineer and advisor. Provider
of the FAPEC compressor [16]. Tutor of Albert Masip, who adapted the data com-
pressor for the computer.

• David Roma Dollase (ICE-CSIC): Electronic engineer in charge of the SDR and
OBC PCB designs.

• Alberta Casas (ICC): Electronic engineer in charge of the OBDH PCB designs.
• Manuel Carmona Flores (ICC): Thermal engineer and advisor, working in the ther-
mal simulations and tests.

• Lluı́s Gesa Boté (ICE-CSIC): Critical software engineer and advisor in charge of
the SW architecture. Tutor of Emilio Garcia, who developed the plugin architecture
as final degree thesis, and David Soldevila, who developed the driver for the RF
communications, as final degree thesis as well.

• Marius Monton Macián (ICE-CSIC): Embedded SW engineer in charge of the sev-

eral firmwares of the system.

• José Bosch (ICC): Electronic engineer and Mechatronics advisor. In charge of

structural elements procurement.

• Joan Mauricio Ferré (ICC): FPGA engineer in charge of developing the cores re-
quired to control the RF transceivers and soma digital buses.

• Carlos Mansanet Gomis (ICE-CSIC): Not officially part of the team, but helped in
the first mechanical design of the system.

• Agustı́ Carrillo Acedo (UPC): Aeronautical engineer in charge of the structural el-
ements design and simulations, while pursuing his Final Degree Thesis.
14 Design and integration of a MP-OBC with SDR for nano-satellites

3 C3 SatP System Design

The Design process carried out so far to develop the C3 SatP computer will be presented
in this section, together with detailed description of the overall design of each of its boards.

One of the key aspects we wanted to exploit, and that is also embedded in the CubeSat
philosophy, is the “modularity” concept. The mechanical modularity of its standard is clear,
but we searched for electronics and SW options and the findings where unsatisfactory:
only a couple of standard digital buses in the infamous PC104 (see Figure 22) whose
pinouts were not shared among different manufacturers and no SW infrastructure or stan-
dards whatsoever. After some discussions, the connector was removed completely, and
changed for as many independent connectors as digital buses we want to provide to the
rest of the satellite (see the connectors and buses offered in Figure 2).

Without the stackable connector, and without enough area to implement all our subsys-
tems in a single PCB, we had to search a new stackable connector in order to follow the
modularity of our philosophy. Looking at the area required, communications and power
consumption, we decided to split the system into 3 boards as mentioned previously: a
master OBC with many connectors to interface with the rest of the CubeSat, a powerful
OBDH with a MPSoC that also has an FPGA section and a SDR that can operate up to
6 GHz. A Samtec high speed hermaphroditic connector was chosen as a reliable way to
communicate with both high and low speed buses and at the same time power all boards.
For more information about the interfaces design process and details, please see Com-
puter Interfaces section 5.

Figure 2: C3 SatP computer bloc diagram of its main subsystems, digital buses and exter-
nal connectors.
Design and integration of a MP-OBC with SDR for nano-satellites 15

The boards would then be disposed in a “sandwich” configuration, leaving the OBC in the
middle (see Figure 23). Needless to say, with this architecture, every subsystem is trans-
parent to the evolution of the other subsystems as long as the I/F between them is main-
tained (pinouts of J15, J16, J17, J19 and J20, their position as well as their surrounding
mounting holes position, see Figure 23). It is also possible to develop other “daughter-
boards” that connect to the MPSoC and implement a different subsystem (e.g. camera’s
Front-End Electronics (FEE), PLM instruments, etc).

Another key aspects we wanted to maintain, is provide as much versatility as possible to

the final user. Our idea is to offer a hardware product with a basic firmware to operate it,
in order to leave room for the user to develop its own SW and firmware applications. In
this regard, our goal is to isolate the final user from dangerous implementations of their
SW that could lead to HW or even mission failure. The OBC in the middle (a.k.a moth-
erboard) will act as the master of the system, booting first, beaconing and establishing a
communication link in order to receive Telemetry and Telecommand (TM&TC) and check
the satellite status. A deterministic and know state in which the OBC can return to in case
of failure increases substantially its reliability. Similar decisions have been made regarding
power supply management, at the cost of reducing versatility. With all this in mind, we
searched for suitable COTS FPGA that could suit our needs.

The Xillinx Zynq Ultrascale+ ZCUE4 [17] [18] was selected amongst many due to its new
Ultrascale+ technology with transistor gate size of 17 nm, which could theoretically be
more resilient to Single Event Upset (SEU) [19] due to its reduced gate size[20] [21]. Also
because it is a MPSoC, with 2 real time processors ARM Cortex-R5, Quad-core ARM
Cortex-A53, 192.000 programmable logic cells in its FPGA section and almost any stan-
dard digital communications bus controller. With its processors working with 0.85 V and its
FPGA banks with 0.72 V, looked suitable for CubeSat applications with an available power
of 3-5 W, but further estimations with Xillinx tools showed a maximum power consumption
(at maximum frequency) of around 20 W. This posed a challenge for its power supply de-
sign as well as the thermo-mechanical design of its enclosures.

Another part in which we wanted to offer high versatility is in the communications sub-
system, implementing an SDR. We searched for the COTS of similar subsystems in the
CubeSat market and finally chose the AD9361, a dual channel full-duplex transceiver ca-
pable of transmitting from 0.047 to 6 GHz and receive from 0.07 to 6 GHz, controlled
with an SPI and read with a custom bus combining GPIO for status and LVDS for data.
Even though it is considered a component with a high TRL (in the CubeSat environment)
since has already flown in other missions [22], past experiences with previous CubeSats
launched by the UPC [23], from Adriano Camps and his Nano-Sat Lab team [11] lead to
a more conservative approach for the communications subsystem. Instead of using solely
the SDR as the main and only link, we will have two separated subsystems: the simple, low
bandwidth but reliable link located in OBC’s PCB, and the new, versatile and powerful SDR
in its “daughterboard”. With this solution we try to satisfy both philosophies, modularity and
versatility, while increasing the reliability of the system. This new reliable link will work in
16 Design and integration of a MP-OBC with SDR for nano-satellites

the 433 MHz industrial, scientific and medical (ISM) radio frequency band typically used
by many CubeSats in order to increase the possible ground stations available to contact
and track it.

From its conception until now, the design has suffered several changes, but at a component
level. The overall design remains as previously explained. The details of this low-level
evolution are shown in the following sections, gathered by board: SDR 3.3, OBDH 3.1, and
OBC 3.2. The current version of the C3 SatP system can be seen in the bloc diagram of
Figure 2, which shows the high amount of digital I/Fs to use by the CubeSat’s subsystems
as well as the internal ones between the main components (each one of them in separated
boards, except for the CC1101, which lays in OBC’s PCB).

3.1 On-Board Data Handler

As mentioned earlier, one of the pillars of the design shall be its versatility, thus we want to
offer as many digital busses as possible while still having room (pins, basically) to program
and communicate with Zynq MPSoC as well as to control the SDR and I/F the RAM mem-
ory, thus we chose Zynq model EG4 with a BGA package of 768 pins. As you can see in-
side the grey box in Figure 3 left, the Media Input-Output (MIO) banks offer almost all stan-
dard digital bus: Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI), Controller
Area Network (CAN), Secure Digital (SD) card interface, GPIO, Universal Asynchronous
Receiver Transmitter (UART), as well as the interfaces towards the Universal Serial Bus
(USB) and Ethernet transceivers, UTMI+ Low Pin Interface (ULPI) and Reduced Gigabit
Media-Independent Interface (RGMII), respectively. The MPSoC will be programmed with
Joint Test Action Group (JTAG) and configured using strap resistors. The DDR4 memory
will be connected through its own dedicated bank and the SDR with the remaining free
banks having Low Voltage Differential Signaling (LVDS) pins.

Figure 3: First version of the OBDH subsystem (left) and current one (right).

After this firs iteration in the design we identified that there is a tendency in the NanoSat
comunity to use the RS485 as a communication interface for the payloads. We agreed
to include it, but Zynq does not have a dedicated controller for this interface. Instead, it
Design and integration of a MP-OBC with SDR for nano-satellites 17

can be controlled with a custom core in the FPGA section of Zynq. It is also interesting to
mention that the result from the study about Zynq’s power supply architecture yield another
useful bus to take into account (please refer to section OBDH power supply design 4.1 for
more details). The chosen “smart” power regulators (called generally Power management
integrated circuit (PMIC)) can be controlled using the PMBus, as well as the MPSoC em-
bedded power manager. This bus will be used by the master MCU to start the power-on
sequence and check the system’s health (voltages, currents and temperature) and prob-
lems (thanks to the PMBus failures protocol). This bus is based on the standard I2C plus
an interrupt line to alert for possible failures, and due to its critical status, it was separated
from the main I2C bus offered to the rest of the satellite.

To select the most convenient banks for the non-defined digital buses (as MIO banks), we
had to perform a pre-routing plan between the connectors (at that time, only J1 and J2)
and the MPSoC. Connectors J1 and J2 where placed exactly above the stackable Samtec
connectors of the other boards (please see Figure 25 in order to have a 1-1 pinout be-
tween them and save PCB area in the OBC (for more information please see section 5).
In this situation, and due to the fact that the SDR subsystem was developed first, J1 and
J2 pinouts were mostly defined and fixed. We tried to use some of the pins dedicated for
power to route the digital buses, but we could only fit 40% of them. We then decided to
add a third connector (Jmio) and use it for the digital buses of the MIO bank. Nonetheless
to say, as every connector have 100 pins, we managed to separate all the buses from each
other by adding a power line (5V) and its return (GND) between them, so to improve sig-
nals quality while providing power to the daughterboard. For more information regarding
the power supply designed for the Zynq please see section 4.1. With the pre-routing plan
done after the Jmio was added we could see the most suitable banks for the SDR, 66 and
65. Also, with the new addition there was no need anymore of stuffing J1 with signals, so
we decided to add another custom LVDS bus for a possible powerful payload.

Many of the digital buses require a transceiver to properly transmit in their medium and
frequency, such as CAN, RS-485, USB and Ethernet. Others do not require a proper
transceiver since they where designed for inter-board communications, but then the volt-
ages used in the signals must match to avoid any damage to the controllers. The Zynq
I/O pins of each bank are capable of operating up to 3.3 V, but not 5 V as many payload
modules do, thus requiring a level shifter. We then decided to operate all banks at 1.8
V to reduce the power consumption, except for the DDR4 ones (which require 1.2 V). All
transceivers are meant to be close to its controller and because CAN requires 3.3 V input,
we decided to add also all level shifters in the OBDH board. With this solution we have
less pin count in the connectors thanks to the transceivers, but at the cost of PCB area
and power supply complexity (two more rails, 3.3 V and 1 V). After a more deep analysis
with real components and the SW selected to design such complex system (Cadence),
we realized the area required was over our constraint of 63x80 mm, and opted another
solution, as can be seen in Figure 3 right.

In its current state, all level shifters are moved to the OBC’s PCB, as well as the CAN, USB
18 Design and integration of a MP-OBC with SDR for nano-satellites

and RS-485 transceivers. Doubts of Ethernet purpose on a CubeSat mission together

with the fact that the RGMII I/F requires 14 signals, made us decide to only provide the
RGMII digital bus in a connector on the board and let the final user develop Ethernet’s
physical layer. During the development process of the other boards (which are simpler
thus faster), we realized the OBDH was not prepared for a stand alone test: it required the
motherboard (a.k.a OBC) for power and communications. With the “stand-alone” approach
in mind, we added a JTAG connector (J5) for programming the Zynq, a UART one (J4) for
debugging purposes and J6 for powering (5v + GND) and configuring the regulators. The
last modification of the design is the addition of J3, a Samtec connector dedicated only to
high speed LVDS signals for a possible powerful instrument. with this modification we can
ensure better signal integrity and at the same time free some space in the motherboard.
For more information regarding the current design of the OBDH system please see section
4.2.

3.2 On-Board Computer (a.k.a.Motherboard)

The OBC is defined as the master of the C3 SatP computer, capable of hosting and con-
trolling two daughterboards: the OBDH and the SDR. It shall also provide a safe state
(minimum energy consumption, solar panels deployed, antennas deployed, etc) in which
to establish the first communications and receive TM&TC in case of an anomaly, thus reli-
ability, in this case, is the driving requirement. In this regard, some precautions have been
implemented, although without recurring to redundancies and high-reliability space graded
components, typical for the space industry.

Figure 4: First version of the motherboard a.k.a OBC.

As mentioned at the beginning of this section, the PC104 was substituted by alternative
Design and integration of a MP-OBC with SDR for nano-satellites 19

connectors to gain some PCB area while providing improved signal integrity at higher fre-
quencies. Two Samtec connectors (J3 and J4 in Figure 4) where chosen between the SDR
and the bottom side of the OBC, while the interface OBDH-OBC at the top required three
(J1, J2 and Jmio in Figure 4) due to the high number of signals coming from the MPSoC
(see Figure 23 for connectors distribution). Connectors to interface all digital buses (both
from the MCU and the OBDH) are distributed along two edges of the board. These two
sides are both provided with a slot to allow the different satellite harnessing to pass through
as well as to connect to the board without flexing the wires too much. As motherboard,
we wanted it to power both daughter boards to avoid using three bulky power connectors,
but at the same time, trying to maintain the modularity of the system. We avoided gen-
erating the voltages required by the SDR and the MPSoC in the motherboard, simplifying
the power tree with only 5V and GND connections to all boards through many pins of
the Samtec connectors. In this situation, any subsystem attached would design and use
its own voltage levels from 5 V, regardless of the OBC version. In the case of the OBC,
only 1.8 V will be required to power MCU as well as 3.3 V and 5 V for the peripherals and
the level shifters and transceivers of the different digital buses (as can be seen in Figure 4).

With this architecture in mind, the SW and embedded electronics experts in our team
searched for a suitable micro-controller that could satisfy the system requirements and at
the same time be capable of implementing risk-mitigation techniques for the space envi-
ronment, such as embedded triple-voting circuitry, radiation tolerant memories, watchdog,
etc. They end up selecting the STM32F446 from STMicroelectronics, mainly due to the
expertise of the team with similar systems but specifically because it is one of the few
models with an embedded CAN controller (used in many CubeSat missions). The CAN
bus is widely used amongst commercial subsystems as a low bandwidth (5 MB/s maxi-
mum) but reliable (immune to Electro-Mangetic Interference (EMI)) way to share TM&TC
between CubeSat subsystems. Although we selected the a model with extended temper-
ature range and protections, this MCU does not implement any defence against SEU. For
this reason, an Ferroelectric RAM (FRAM) was added as booting backup. Together with an
Error Detection And Correction (EDAC) scheme implemented and an external watchdog
we believe it could withstand the Low Earth Orbit (LEO) environment for several months. A
SD card is also available, which could also be used as a backup for the booting code and
configuration, but not intended for this purpose at this phase of the project, as can be seen
in Figure 4. It will be mainly used as a hard drive to store payload data and information
while the satellite waits for the proper command to transmit it to ground and also to store
the Linux image required to boot the operating system of the OBDH. It will be placed in the
OBC’s PCB in order to save some space in OBDH’s board.

All this de-risking methods to increase system’s reliability where complemented with the
addition of an Inertial Measurement Unit (IMU) and another Radio-Frequency (RF) link,
apart from the SDR. The IMU is conceived as a back-up sensor for the ADCS subsys-
tem, as well as to provide HK information to know the attitude of the satellite in case the
ADCS is off-line (at deployment, commissioning phase, in case of anomalies, etc). It is
based on Micro-Electro-Mechanical Systems (MEMS) technology with a digital interface,
20 Design and integration of a MP-OBC with SDR for nano-satellites

making it ideal for space applications due to its low power and its intrinsically radiation
tolerant mechanisms. As mentioned at the beginning of the section, the low bandwidth
RF link was conceived to be a reliable way to communicate with the CubeSat in case of
an anomaly or at the event of an unexpected reset, or simply after deployment. After the
MCU boots or it returns to the “safe” state due to a malfunction, the transceiver will start
beaconing to ease the satellite tracking, while awaits for TM&TC to proceed (download
status, turn-on X subsystem, uploading new firmware, etc.). Even though not featuring full
duplex communication, the AX5042 at 433 MHz was the chosen transceiver due to its flight
heritage and wide use amongst european radio amateurs (and, hence, well characterized).

Although the OBC is considered the master of the system, it shall comply with the require-
ments imposed by the daughter boards, so their evolution will also impact OBC’s design
(please see the current version in Figure 5 left). For example, Samtec connector pinouts
were defined by the SDR design, as well as Jmio ones after selecting the wanted digital
buses from the OBDH. After choosing the power supply architecture of the Zynq (see sec-
tion 4.1), we decided to implement the same approach in the OBC’s board by using the so
called PMIC, providing 3.3 V and 1.8 V. Also, area restrictions imported the transceivers
and level shifters from the OBDH board (later ones not represented in Figure 5), and mod-
ified the connectors type and distribution: every bus with its own independent connector
(Molex PicoBalde, micro-USB, etc.) and LVDS and Ethernet connectors removed (they are
now on OBDH’s board).

Figure 5: Current version of the OBC (left) and its Stand-alone version (Right).

The design of the OBC was adapted accordingly, but also modified following its own inde-
pendent evolution. In this regard, while searching for a suitable FRAM to use as a boot
option, we realized that the MCU had no interface for external memory booting. Instead of
finding another MCU (some MSP430 from Texas Instruments have an embedded FRAM),
we opted to use the its internal memory for booting. The SD card can not be used for
booting as well, but accessing to its contents while the OBDH is offline would increase
system’s modularity and reliability. For this reason, a digital multiplexer was added, so
the SD card can serve as the hard-drive for both OBC and OBDH. The RF transceiver
was also modified, but due to an unexpected shortage of AX5042 stock in several of our
distributors. The team opted for the CC1011 transceiver model from Texas Instruments,
Design and integration of a MP-OBC with SDR for nano-satellites 21

due to its similar features and performance (433 Mhz with full-duplex). It was also selected
because our main distributors have plenty of them in stock and the opensource community
can provide with the baseline firmware to operate them, reducing its development costs.

In order to take advantage of system’s modularity and ease its integration in smaller mis-
sions a stand-alone version of the C3 SatP computer was defined (please see Figure 5
right). It was conceived for those missions not requiring a powerful data handler or high-
speed communications but a reliable OBC. Its datasheet, with the features and perfor-
mances, was written by Carles Sierra with help from the team (please see Appendix F).
The two versions should use the same components to reduce engineering efforts to test
and validate the system (or at least the OBC). The difference between them is the non-
population of those components not used in the stand-alone version (daughterboard’s con-
nectors, transceivers, level shifters, etc).

3.3 Software Defined Radio

The main reason to choose the AD9361 was its flight heritage and its frequency range (up
to 6 GHz). Once selected and defined a reasonable I/F between SDR and OBC’s boards
(see section 5.2.1), we proceed to develop the PCB. It was designed using KiCad and
mounted in a company called Promax, due to the high precision required in positioning
and soldering AD9361 BGA package and the Samtec connectors. The geometry of the
board (63x80 mm) was chosen having in mind a possible motherboard underneath with
maximum 90x90 mm, and positioning 2 connectors at each side, as seen in Figure 6. Its
PCB mechanical drawing, which will later be used as template for the OBDH board, can
be seen in the appendix B.

Figure 6: SDR board ready to be tested.

As it was the first system to be developed, we had no OBC to control and test it, so we
made an adapter to connect it to the Trenz ZCU102 evaluation motherboard [24], where
we had an FPGA with the required firmware to operate the SDR. Everything worked fairly
strait forward, we could communicate with the transceiver and generate the desired RF
signals using the default manufacturer’s firmware. Once finished, we developed a metal-
lic enclosure to increase EMI and radiation shielding while improving thermal dissipation
(please see section 6). We are now developing a wrapper for the FPGA core that controls
it in order to simplify its integration with the SW architecture of the system.
22 Design and integration of a MP-OBC with SDR for nano-satellites

4 On-Board Data Handling design

The following sections explain the design process and evolution of the OBDH power supply
(section 4.1) its layout implementation (section 4.1.5) as well as the PCB design and the
routings of the digitalbuses (section 4.2)

4.1 Power Supply

In this section, the design process and evolution of the OBDH power supply stage is pre-
sented. Power requirements of the MPSoC are explained in the first section (4.1.1), in
order to better understand the solution adopted in the next chapter (4.1.2). Once selected,
the prototype to validate its functionalities has been developed and tested, which is pre-
sented in sections 4.1.3 and 4.1.4, respectively. The results and current status of the power
supply in the OBDH is presented in section 4.1.5.

4.1.1 Analysis

One of the main issues of the MPSoC is their power supply. Usually these systems have
different embedded circuits working at different voltages, and must be powered on in a
given sequence. As the technology progresses, core voltages are lowered to reduce power
consumption, but in a powerful system such the Zynq Ultrascale+, maintaining a core volt-
age of 0.72 V and 0,85 V forces the current to increase up to several amperes (depending
on the application and the frequency used, could increase up to 20 A or more, estimated
with the Xillinx Power Estimator (XPE) [25], thus also posing a challenge for the design of
its power supply. Another matter into consideration is the fact that the system shall survive
the harsh environment of space, where Single Event Latch-up (SEL) is a very possible
thread to our electronics and the safest way to address it is to include resetable circuit
breakers (avoid fuses) at the power supply stage that will disconnect the whole circuit in
case of a HW failure. Moreover, it is known that a malfunctioning power supply unit is
responsible of a great percentage of mission failures, not only in the CubeSat industry. It
is then very useful to gather in-flight HouseKeeping (HK) data to analyse its health and
avoid possible harmful satellite operations. All this requirements, together with the low
area available in the OBDH PCB, makes it a very challenging design (even though it uses
COTS and not expensive, resilient, space graded components).

Taking a closer look to Zynq power distribution systems in Xillinx UG583 [26] where it
explains the different ways of powering our MPSoC, the reader can easily see the high
amount of power inputs it needs (see Figure 7). In this particular configuration (full power
management versatility) a total of 14 (plus each different FPGA GPIO banks voltage) reg-
ulators will be required, mainly due to sequencing requirements and the possibility to turn
on and off different sections of the same component. As our philosophy is to offer as much
versatility as possible, the first approach was to follow the said configuration, but the team
quickly realized it was unfeasible: too much PCB area required and too risky for a space
Design and integration of a MP-OBC with SDR for nano-satellites 23

mission (many single point failures). Instead, we looked for the simplest way to power the
Zynq, with the least amount of regulators possible but still complying with the sequence
requirement.

Figure 7: Complete power distribution architecture for Zynq Ultrascale+.

In the first iterations we manage to reduce them to 8, used to power Processors (0.85V),
DDR4 controller (1.2V), FPGA core (1.2V), Auxiliary (1.8V), banks Input-Output (I/O) pins
power (1.8) and the different peripherals on the OBDH PCB: DDR4 components and ter-
minations (2.5V), level shifters (3.3V) and an Ethernet transceiver (1V). As mentioned in
the OBDH Design section (3.1), we later decided to move all peripherals to the OBC’s
board (or externally, as in the case of Ethernet) to free some space for the power supply,
DDR4s and the high amount of routing required to route the MPSoC towards the OBC.
With this new configuration (and the current one) the 3.3V and 1V regulators became ob-
solete, and were removed. In summary, the power supply shall comply with the following
requirements:

• Supply the required nominal voltages (6) to all banks and rails of the Zynq Ultra-
scale+ MPSoC.

• Power on the device following its required sequence.

• Regulators must be capable of delivering several amperes in an efficient way.
• Provide the necessary protections against over-current, over-voltage, under-voltage
and over-temperature situations.

• Acquire HK data for system health analysis.

• Respect the area available in OBDH PCB.
• Avoid using military or space graded electronic components.
24 Design and integration of a MP-OBC with SDR for nano-satellites

4.1.2 Solutions

As the MPSoC can be considered a high power application (∼ 4 W) in a CubeSat mis-

sion (∼ 1 W per 1U), we searched for the most efficient architectures: switched DC/DC
converters. There are many companies offering a wide variety of regulators, and during
the first searches, we realized there were 2 main features that could impact seriously our
design, which needed a trade-off analysis (see Figure 8).This were multi-regulators in one
package (vs. single ones) and smart converters (vs. without digital circuitry). We also
took into account a cold-redundancy scheme during the study, but that only adds area and
complexity to the system (although required in bigger missions) and was quickly discarded
as an option. Of those available (1, 3, 5 and 7), the last one seems the most suitable
due to its efficiency, control and telemetry architecture simplicity, but the area required is
too much for the space available. Its was discarded in favor of the second most suitable
option, the third, multi-regulators in one package with smart IC for control and telemetry,
also referred to as PMIC.

1 30x30 mm x3 ICs (taking into account passive components) + sequencers + monitoring and protection
2 30x30 mm x3 ICs (taking into account passive components)
3 13x12 mm (taking into account passive components) x ¿=9 ICs + sequencers + monitoring and protection
4 19x21 mm (taking into account passive components) x ¿=9
5 2-3 high temp spots. Reduced efficiency if not radiated
6 ∼ 8 hot spots distributed among the board
7 Found devices have the efficiency maximum above 10W. High temperatures also decrease efficiency
8 Independent rails allows to select devices with maximum efficiency In our nominal conditions and also reduce temp, therefore better efficiency
9 Enable signals select which rail boots or shuts down and automatic shut down from the protection circuit
10 Time delays for sequencing and protection triggers HW implementation
11 Redundant units could have more safe margins than nominal ones (relaxed delays in sequencing and/or lower protection thresholds)
12 Time delays for sequencing, protection thresholds and error management re-configurable via SW
13 Additional electronics required to add telemetry capabilities
14 Relative to the lowest one (solution 3)
15 Assuming Error handling and management solution via SW.

Figure 8: Table depicting the trade-off analysis of different solutions regarding regulators
architecture

Once the PMIC architecture was selected, we searched the main manufacturers for suit-
able components, such as Texas Instruments, Analog Devices, Infineon technologies or
Intersil (now Renesas). All of them offered PMIC solutions with minor differences, as can
be seen in the table of Figure 9. Texas Instruments offered the most complete PMIC avail-
able in the market at that time, the TPS6508640, with 6 buck converters, 4 Low DropOut
(LDO) regulators and 3 switchers, but without all the protections we were seeking. Intersil
also had an interesting smart regulator with all the required passives embedded (a rela-
tivelly big inductor and a capacitor) and offered a solution for our application with multiple
Design and integration of a MP-OBC with SDR for nano-satellites 25

regulators in parallel sharing a synchronisation signal. Even though having many passives
integrated inside its package, the area needed for the 8 rails required at that time was
too much. We end up choosing the Infineon IPRS5401 due to its area and protections
(although it is not the most efficient regulator), with 4 buck regulators (A, B, C and D) plus
a LDO, thus requiring 2 of them.

1 5V input required from motherboard

2 Rail 5 (1,2V) will be generated from rail 4 (1,8V) with a LDO
3 Two PMIC required, possible option to combine outputs for a current increase
4 2 outputs could be combined to supply up to 8A / 6A, or use an external PowIRStage (6/15/25 A)
5 15 stored configurations, useful as backup when a cosmic ray hits the memory.
6 Efficiency increase on light loads thanks to the Adaptative on Time (AOT) feature
7 Add TD21240 for up to 40 A
8 Additional Pre-Bias Startup protection
9 Inductors and passive components embedded
10 Easy to add components in parallel for greater output current and/or redundancies (AN2034)
11 It has the DDC serial bus option to parallel the components and improve efficiency by offsetting switching phases of the converters

Figure 9: Table depicting the trade-off analysis of different PMIC solutions

4.1.3 Design

As the selected PMIC is a step-down (a.k.a Buck) converter, we needed 3 parameters

to start the design: input voltage, output nominal voltage, and nominal current. Target
nominal current would be supplied by the XPE with a typical application for our MPSoC
(FPGA section and processors sharing computational load). The input voltage would be
5 V as many commercial EPSs offer it and the output voltage would be defined by Zynq
Ultrascale+ requirements.

Figure 10: Buck converter model.

With the input voltage and the output requirements, we moved on to determine the induc-
tor’s and capacitor’s values for each rail, with the model represented in Figure 10, from
Texas Instruments Application Note slva157 [27] and slva477b [28]. A Buck converter ba-
sically uses an inductor to store energy (in the form of “current”, see equation 1) when
26 Design and integration of a MP-OBC with SDR for nano-satellites

the switch (SW in the Figure) connects it to the input, and release this energy when the
switch is off, maintaining the current through the load, thanks to the diode D. The Ca-
pacitor Cout is used to smooth the ripple produced by the turning on-off of the switch and
provide enough and fast current in case of a sudden change in the load (e.g. MPSoC
turning on the FPGA section). The inductor’s voltage and current behaviour in equation
1 and 2 indicates that the inductance (L) is proportional to the output voltage and ton but
inversely proportional to the target current: hence, for lower voltage values (e.g. 0.72 V for
the FPGA core) and relatively high currents (around 2 A), the inductance selected will be
lower than for a higher voltage and lower currents, as can be seen in the table of Figure 12.

With a given L, the output voltage varies linearly with the amount of time (D) the SW is
closed, as can be seen in equation 3. The output voltage of the converter is selected by
tuning the % of time the switch is on, also known as Duty Cylce. The IRPS5401 has a
feedback pin dedicated to sense the output voltage at any time and adjust the Duty cylce
to maintain a nominal value.

∂IL
EL = 1/2 · L · IL2 −→ VL = L · (1)
∂t
 
 (V −V ) at t  R ton VL ∂t = VL · t at ton
in out on L on
VL = ∆IL = R0 L (2)
 −V at to f f  T VL ∂t = VL · (T − t ) at t
out ton L L on of f

ton = D · T & to f f = (1 − D) · T −→ Vout = Vin · η · D (3)

Rewriting the previous equations, the ideal inductance would be calculated using equation
4, with a high switching frequency ( fS , given by IRPS5401, between 800 KHz and 2 MHz)
to reduce the current ripple in the inductor (∆IL ). To increase the efficiency, one must
validate that the inductor’s current ripple does not exceeds 50% to avoid entering into
discontinuous mode with the selected L using equation 4. In this mode, the capacitance
would provide current not only to the load, but also to the inductance, hence reducing
overall efficiency and requiring an increase in Cout size to avoid under-voltage situations.
Another important condition to take into account is the maximum constant current the
inductor can withstand, which is related with the parasitic DC resistance of its copper coil.
It will determine, basically, the physical size of the component, as thicker coils reduce their
intrinsic resistance, reducing the joule effect, allowing more current to pass through without
melting the copper.

Vout · (Vin −Vout ) Vout · (Vin −Vout )

L= −→ ∆IL = < 50% (4)
∆IL · fS ·Vin L · fS ·Vin

Once the inductor is validated to operate, ideally, around a 20% current ripple, we can then
select the required capacitor for the maximum allowed voltage ripple (∆Vloadmax ) and the
Design and integration of a MP-OBC with SDR for nano-satellites 27

maximum allowed voltage over-shoot (∆Vos ) at the load (the MPSoC). As can be seen in
equation 5, the total amount of ripple at the output of the buck (∆Vtotal ) is produced by two
phenomenon: the inherent ripple due to buck converter’s nature (∆Vout ) and the imper-
fections of real commercial capacitors (∆VESR ). The Equivalent Series Resistance (ESR)
refers to the parasitic resistance all capacitors suffer, by which a small voltage variation
occurs in the presence of a variable current (∆IL ).

∆Vtotal = (∆Vout + ∆VESR ) ≤ Vloadmax = 3% −→ ∆Vout ≤ 3% − ESR · ∆IL (5)

Usually capacitance and volume have a positive correlation in electronic components,

hence it is interesting to search for the minimum required Cmin in order to save PCB area,
mass, and number of components, while complying with the ripple and over-shoot re-
quirements. The equation 6 shows the relationship between the inductor’s current ripple
(∆IL ), output voltage ripple (∆Vout ) and the minimum capacitance required. The equation
7 shows the relationship between the current ripple (∆IL ), inductance (L), nominal output
voltage (∆Vout ), maximum over-shoot allowed (Vos ) and the minimum capacitance required
to ensure that over-shoot.

∆IL ∆IL
Cmin = −→ ∆Vout = ≤ 3% −VESR (6)
8 · fS · ∆Vout 8 · fS ·Cmin
2 ·L
∆Iout 2 ·L
∆Iout
Cmin(os) = −→ Vos = ≤ 3% (7)
2 ·Vout ·Vos 2 ·Vout ·Cmin

As in the case of inductors, only a given set of values are commercially available, hence,
engineers shall instead validate that the chosen component complies with equations 5, 6
and 7. The difficult task is to find a big enough capacitor with the minimum ESR possible,
as this two parameters usually vary in opposite ways: bigger components, greater parasitic
effects. Thanks to its nature, capacitors can be connected in parallel to increase the total
capacitance, and at the same time, reduce the ESR. Furthermore, using different types of
capacitors it is possible to accomplish great capacitance values (e.g. tanalum capacitors)
with very low ESR (e.g. ceramic capacitors). Using this approach, we selected a tantalum
capacitor for all the rails, having in mind the high amount of ceramic capacitors used for
decoupling the MPSoC, which reduce the ESR to less than 15mΩ.

4.1.4 Prototype and Test

Once the IPRS5401 was finaly selected, we wanted to test and validate its functionality to
ensure it is the right choice for our application. Another reason to develop this prototype is
to have a hands-on experience with the component and learn valuable lessons that might
impact the final implementation of the power supply.
28 Design and integration of a MP-OBC with SDR for nano-satellites

As the project had a short budget, we searched for open-source electronic design tools for
our prototype. KiCad was selected mainly due to its simplicity (faster simple designs) and
the fact that all related files are text only, which can be helpful if integrated with a repository
like BitBucket or Git. The GitLab integration was straight forward and the version control
worked, but we had to take precautions when updating the PCB design: Is almost impos-
sible to perform a proper merge of text that represents an image. The merge is possible
in KiCad if engineers developing the PCB design, work in different parts, without crossing
their borders. Even though, the final result must always be checked.

Tthe prototype was conceived at the beginning of the project, where the OBDH still had
all the peripherals in its PCB. We focused our efforts in designing a PCB that could test
if the component is able to supply the power needed at each rail, if the protections work
as expected or if the digital I/F is suitable for controlling and configuring safely the PMIC.
For this, we made some assumptions, which differ from the final implementation (except
for the 5 V input):

• input voltage would be 5 V as in the final implementation.

• Regulator’s configurations will be performed by Infineon’s I2C dongle, together with
the PowIRcenter SW [29].

• target current for each MPSoC rail would be supplied by the XPE, configured with a
high demanding application.

• Two of the switchers in the IRPS5401 will be used together (C and D) to stress the
component to its limits.

• Peripheral’s power will be provided by the embedded LDOs.

Using Kicad and GitLab, we developed the prototype seen in Figure 11. Several high
power resistors distributed at each rail serves as a static load allowing currents between
1 and 8 amperes (depending on the rail). LDOs where used to generate the rail’s voltage
that required the lowest currents, such as the 3.3 V and 2.5 V ones, for the peripherals.
Switchers C and D where connected together to generate up to 8 A for the FPGA and
processor’s rails. Two banana connector holes where provided at each rail to allow a cur-
rent prove (based on the Hall-effect) sense the output current (at the end, we soldered
the red wires shown in Figure 11 instead of using bananas). To ease the control of the
PMICs, a dual standard header was provided in the middle of the board, compatible with
the MSP432 from Texas instruments. Attaching it underneath, we could turn on and off
each of the rails by means of GPIO, and configure them with a PMBus or I2C bus (not
used at the end, due to the lack of time available to develop a custom firmware). A 3-pin
standard header was also implemented to configure and control the PMICs externally, with
the I2C dongle from Infineon. Tantalum and ceramic capacitors used to smooth ripples, but
with a lower number of components due to the fact that the load is static and would not re-
quire a proper decoupling. Coil’s where selected using the equations from section 4.1.3 but
with greater target currents and without taking into account the joule effect of the inductors.
Design and integration of a MP-OBC with SDR for nano-satellites 29

With this features implemented in the design, we generated the gerber files and sent them
to LabCircuits in order to manufacture the PCB. As the board is fairly simple (with big
footprints, except for the PMICs, as they are embedded in a BGA package), we could sol-
der all components manually at the ICE-CSIC laboratories. Once done, we developed a
simple firmware to control the GPIOs and hence the rails, while using the I2C dongle to
configure them, in order to start the testing campaign. Unfortunately, no formal nor sys-
tematical approach was used to test the different features, hence, the following paragraph
will summarize the validated features as well as the issues we encountered, and how we
overcame them for the final implementation in OBDH.

Figure 11: Picture of the mounted PMIC prototype PCB

One of the first things we checked was the communication and configurations of the PMIC.
Configuring them was straight forward using the I2C dongle, and the firmware to turn on
and off each rail also worked, but its internal non-volatile memory did not. The datasheet
states that after a power-up, internal control registers will be loaded with the configuration
stored in one of the memory banks, which is selected with an external resistor. We dis-
covered, and later corroborated by the manufacturer, that the configuration loaded into the
control registers is not the one selected by the resistor, but the last one to be written. It is a
known issue that the manufacturer will correct in future versions of the component. GPIO
control was also successful, we could turn on and off individual rails with the sequence
established by the MSP432, and validate their timings with the Power Good pins, but after
testing the capabilities of the communication bus, we decided to change this approach.
Instead of controlling the sequencing with GPIOs, we will configure and control the PMICs
via SW.

As the PMIC is able to gather information regarding the output voltages and currents for
each rail as well as the temperature of the component, we checked the accuracy of this
readings. With an oscilloscope for voltages, Hall-probes for the currents and an infrared
camera to see the board’s temperature, we validated the accuracies and resolutions stated
in the datasheet of the component. Voltage and temperature reporting was compliant with
our stability requirements, but the currents posed a concern when defining the protections
for the MPSoC, as the output current resolution is 125 mA. The threshold should be set
as close as possible (but still above) to the maximum current level for a given rail, in or-
30 Design and integration of a MP-OBC with SDR for nano-satellites

der to trigger the Over-Current Protection (OCP) as fast as possible and avoid irreversible
damage due to a SEL. As the current use will be determined by the specific application
in the Zynq, the thresholds will be set empirically, once this application is defined for a
given mission. Another issue related with the OCP is the in-rush current at power-up, due
to the high amount of capacitors between the PMICs and the MPSoC. When enabling a
rail, the power will be first transmitted to the capacitors, and later to the Zynq. This charg-
ing is very fast, hence the current transmitted increases abruptly at the beginning until all
capacitors are charged, which might be above the OCP threshold. In almost all rails we
faced the same problem: the rail was disconnected at power-on due to the OCP detecting
too much current (although not dangerous for the Zynq). The current spike is also related
with the fast voltage variation seen by the capacitors, hence, we forced the PMIC to set
the output voltage with a slower slew rate (around 15 ms) to reduce the in-rush current to
acceptable levels. Still, the OCP, Over-Voltage Protection (OVP), Under-Voltage Protec-
tion (UVP) and Over-Temperature Protection (OTP) will be finally defined once the OBDH
is designed, manufactured, and programmed for a specific mission.

The main unexpected result from the prototype was the heat generated by the regulators
and its coils. As explained in the design section (4.1.3), the less voltage and the more
current a rail has to provide, the less inductance it requires (please see the table in Figure
12). We selected two small coils (the small black squares around the PMICs) for the most
powerful rails, with enough inductance for their operation, but without taking into account
the coil’s DC resistance. With 6 A and 8 A flowing through them (to stress the regulator to
its limits) and an RDC of 0.1 Ω, the coils were dissipating 3.6 W and 6.4 W, respectively.
With less than 5mm3 in volume, they increased their temperature to more than a 100 de-
grees in a few seconds. As the XPE showed, the final implementation will not use (nor
allow) such currents to pass though the inductors, but still, we revised the coil’s selection
and changed the model for a more suitable one, with one order of magnitude lower DC
resistance, at the cost of an increase in size and mass.

The conclusion from the test campaign is that the IRPS5401 is suitable for our mission,
despite the issues we encountered. We are confident that the final design, explained in
the following section, address this issues and increase the reliability of the system. Also
mention that thanks to the results of this prototype, we decided to use the same regulators
for all C3 SatP boards and share the same digital communications bus in order for the OBC
to control the turning on and off of each of the subsystems.

4.1.5 Results and future work

After testing the regulators in the prototype and conclude they are a good option for our
system, we moved to design what is the current version of the power supply for the Zynq
Ultrascale+ on the OBDH. The high level design of the OBDH suffered changes during and
after the PMIC prototyping, hence, for this design we followed the new requirements, listed
in the requirements analysis section (4.1.1).
Design and integration of a MP-OBC with SDR for nano-satellites 31

Regulator’s coils were redesigned to account for a lower nominal current and to reduce
losses due to the Joule effect. We selected the XAL50 family of power inductors from
Coilcraft due to their low DC resistance (between 0.013 and 0.09 Ω), their small footprint
(5x5 mm) and their metallic shielding (which we hope it reduces EMI while increasing ther-
mal emissivity in vacuum). Bulk tantalum capacitors remained the same, but new ceramic
capacitors with smaller footprints (SMD 0406, 0805, etc) were selected with the same ca-
pacitance. The resulting parameters calculated from the step-down converter model in
section 4.1.3 with the new requirements can be seen in the table of Figure 12.

Figure 12: Table summarizing the design parameters for each of the MPSoC rails. Note
that in the schematic of Figure 13, R3 2V 5 DDR V PP corresponds to rail R6 in this table.

Other minor changes have also been added to the current schematic (please see Figure
13) which accounts for the changes done at system level (explained in section 3). One
of this changes is the removal of the OBDH peripherals (level shifters, transceivers, etc),
hence, 3.3 V and 1 V rails were removed from the design (no LDO will be used). Also,
by that time, the power consumption estimations were refined and in order to better dis-
tribute the heat produced by the regulators and coils, the required rails were redistributed
amongst both PMICs. In this situation, PMIC 1 would provide around 3 W of maximum
power, and PMIC 2 around 2.5 W (whereas in previous configuration was 4 W and 1 W,
respectivelly). As current requirements were also relaxed, there was no need to connect
switchers C and D together to produce between 4 and 8 amperes. Instead, only the most
powerful rails are connected to switcher C (R1 in regulator 1 and R2 in regulator 2).

After the prototyping phase we realised that PMICs digital interface provides more control
and much more information than with simple GPIOs singals (Enables for each switcher,
Sleep and Power good (PG) pins), hence, we removed the PG pins and left only the sleep
and 1 enable for each regulator (which might still be removed in the future if testing of the
first OBDH version is successful). As this regulators were also selected for all the C3 SatP
boards with a common HK bus, every PMIC shall have a unique address. We made sure
all regulators have a different resistor to differentiate them (see R95 and R107 in Figure
13).

This design has been added to the OBDH electronics schematic (please see appendix E),
but as the PCB design is still ongoing (please see section 4.2), we delayed the tests for a
near future.
32 Design and integration of a MP-OBC with SDR for nano-satellites

Figure 13: Schematic of the PMIC final implementation developed with Cadence Allegro
Design SW. Note that here R3 2V 5 DDR V PP corresponds to rail R6 in the table of Figure
12.

4.2 Layout design

The design process and evolution of the OBDH PCB is presented in this section. To
give some perspective, a short summary of the main components and their challenges
is explained in the first part (4.2.1), followed by the definition of board’s layers (4.2.2). A
more detailed power stage design implementation is then explained in same section, as
well as the route planning for the digital busses. As the design is still open due to several
“show-stoper” issues, the current status and future challenges are presented in section
4.2.3.

4.2.1 Analysis

As mentioned in the system design section (3.1), Level shifters and transceivers required
by several digital buses from the MPSoC were moved to the OBC PCB in order to free
some space in this board, and will not be explained in detail in this section. The systems
is mainly composed by the MPSoC, the DDR4 memory chips required by the Zynq Linux,
the power stage for all components and the different connectors to interface with the OBC
and external payloads (see Figure 14). The main challenges offered by this components
are presented in the following paragraphs to better understand the decisions made during
the hardware design.

The Zynq Ultrascale+ XCZU4EG was the model selected for the MPSoC of the OBDH.
Apart from its complex power supply (designed in section 4.1 and implemented in section
4.2.2), the team had concerns with the physical interface to communicate with it: a 768
pins BGA package with a pitch of 0.8 mm. With this separation, it is impossible to route
all signals and respect their impedance and timing requirements with a dual layer board.
Instead, a multi-layer approach will be used, which requires a careful design of the width
Design and integration of a MP-OBC with SDR for nano-satellites 33

of the dielectrics to comply with the requirements (please see section 4.2.2). Thermal
dissipation of the component has also been an issue (maximum power consumption of
around 4 W), as the board only interfaces the OBC with a very high thermal resistance.
To help reducing this thermal resistance, several mechanical elements were developed,
which can be seen in section 6.

Figure 14: Images of the main OBDH components. From left ro right: DDR4, MPSoC and
PMIC.

The most restrictive constraints for the PCB design comes from the two DDR4 memory
chips. With a maximum working frequency of 2.6 GHz and a BGA package of the same
pitch (0.8 mm), it requires several layers to be properly routed (6 in our case), a controlled
track width in order to maintain the same impedance through all the board as well as simi-
lar track length for all the signals of a given bus (addresses, data, control, etc) so the set-up
and hold times are respected (please see Figure 33). In fact, due to their complexity, sev-
eral issues (still open) have raised from the modifications performed to the board in order
to comply with their requirements (more information in section 4.2.3).

Due to the complexity of thess systems, the team realized that another electronic CAD SW
should be used instead of Kicad, since it lacks several key high-speed signal design fea-
tures, such as group delay analysis and tuning, signal integrity analysis, etc. and a good
constraint manager to take into account the high amount of requirements for each signal.
The team was interested in two professional applications: Cadence PCB design tools [30]
or Altium Designer [31]. Both have similar features but Altium outstands due to its online
components database that gathers availability, price, and footprints from the main distrib-
utors such as Farnell, Mouser, DigiKey, etc. Another interesting characteristic from Altium
is its version control, where several people could work on the same board in parallel, as
it integrates a git compatible environment. We finally selected Cadence basically due to
the costs associated with their licence. While Altium asked for one license more than 1000
e(they considered us as a private company), Cadence floating licences where available in
ICC servers, at no cost to the project. Setting up the custom version control environment of
Cadence was considered not worth the time just for two engineers working in the OBDH,
hence, the engineers working in this board had to develop the schematics and the layout
sequentially.

The power stage design had some issues too, but not that problematic thanks to the pro-
totype we developed. As their communication signals are not considered high-speed (less
than 400 Kb/s), impedance matching is relaxed. Also, power transmission will be per-
formed by copper planes inside the board, simplifying the routing. In this case the main
34 Design and integration of a MP-OBC with SDR for nano-satellites

constraint is related to the volume of the components and their footprint areas. With two
IRPS5401 of 7x7 mm, plus 6 coils of 5x5 mm and 6 bulk tantalum capacitors of 5x3 mm,
they occupy approximately 25% of OBDH PCB area (see Figure 16). Height is also impor-
tant to take into account since 3 of the coils measure 5.1 mm, which might interfere with
the top OBDH metallic cover (for more information see section 6).

High-density connectors were also important in the design, since a bad distribution of pins
in them could lead to an increase of board layers (to provide a “bridge” for a given pair of
signals that intersect), which increases its mass and the manufacturing costs. As men-
tioned in the System Design section (3), the SDR board was developed first, defining most
of the pinouts of the lateral Samtec connectors and their positions (board dimensions as
well). The MPSoC and its DDR4 were placed in the most suitable orientation for routing
those pins. The second board to be developed was the OBC, but in order to close the de-
sign with all the external connectors, transceivers and levels shifters properly connected,
we had to define the pinout of the Jmio connector. In this case, the OBDH design would
define them in order to mitigate possible intersections. To do so, a pre-routing plan was per-
formed manually, since Cadence was still not chosen as main design SW. Although it was
a very time consuming task, we managed to estimate the pinouts with a minimum number
of intersections and layers (4, but possibly 5 taking into account uncertainties).

4.2.2 Design

One of the most important aspects of PCB design is defining the layer distribution and
the thickness of each one of them. Depending on the geometry of the tracks (a.k.a strip-
slines), the reference planes around them and the type and thickness of the dielectric in
which they are embedded, the characteristic impedance (Zo ) of the track changes (please
see the typical geometries considered in Figure 15 left). For high-speed designs it is
mandatory a good impedance matching along the tracks, even if they go through different
layers with different thicknesses.

Following the advice from Xillinx when designing a board stack-up for a DDR4 [26] and
using the ZCU102 [32] as example, we defined the layer’s distribution seen in Figure 15
right, but without layers 18 and 19. We wanted to use the minimum required to properly
route the RAM memories, but during the process we end up needing one more. Conceived
in a symmetric way to allow high speed interfaces with both top and bottom layers, a core
of power planes (in red) is surrounded by 8 pairs of signals (in orange) and ground planes:
4 above, and 4 more underneath. Each signal layer rest between 2 ground planes that help
screening EMI from other high speed signals and shorten the return path of the current
(allowing thinner tracks), a good practice to improve signal integrity at the cost of a thicker
PCB.
Design and integration of a MP-OBC with SDR for nano-satellites 35

Figure 15: Typical micro-strip’s sections used for Zo calculations (left, courtesy of Mantaro
[33]) and layers from OBDH PCB (right). Dielectric layers between them have been omitted
for convenience.

Once defined the order and functions of each layer, we contacted the future assembler of
the board, LabCircuits, to see their manufacturing capabilities: dielectric materials offered,
copper thicknesses available, surface coatings, etc. as well as the physical parameters of
this materials to properly design the geometry of our stack-up and tracks. The selection of
the best material is a complex task that involves tacking into account many requirements
from different aspects of the system, such as performance in vacuum and at high temper-
atures, component’s footprint geometries, manufacturing limits, etc. as well as electrical
requirements of the fastest signals. After some iterations, the stack-up in appendix C was
defined, which is currently being used in the layout design.

As you can see in Figure 15, the total width of the board measures 3.35 mm, very thick
compared to a standard multi-layer board (∼ 2mm). With so many layers and high-speed
signals, the dielectrics contribution to the thickness is very high (∼ 87%). During the
summer break, we realized an issue with one of the manufacturer’s capabilities concerning
via’s geometry and the total thickness of our stack-up, which might require a revision of the
layers and their dielectrics. For more information please see section 4.2.3.

As the design SW chosen for this board was Cadence, we could not take advantage
of the already designed schematics and footprints developed for the power stage proto-
type. Hence, the first task was to generate the components metadata, where it gathers
schematic symbol and footprints depending on the package. We created the schematic
symbols and footprints of the components not stored in Cadence database (such as typi-
cal connectors, passive components, some integrated circuits, etc): the IRPS5401 and its
coils. Once done and added to the schematic design (see Figure 13), we move to start the
placing of the footprints in the available area of the board.

As can be seen in Figure 17, the MPSoC (the big square) was placed in the middle of the
board with the proper orientation to ease the routing towards the lateral Samtec connec-
tors. Lateral connectors and the mechanical holes at each corner were already defined by
36 Design and integration of a MP-OBC with SDR for nano-satellites

SDR’s PCB design and they required a fixed position for a proper integration. The FPGA
was slightly shifted to the right to allow the positioning of the DDR4 memory chips near
its RAM physical interface (the top left corner, see Figure 33). Even though this compo-
nents are in the board’s top layer while the connectors lay at the bottom, they can not
overlap, since the way to connect to them is by means of vias close to their pins. In this
case, BGA packages and the Samtec connectors can be considered “through-hole” com-
ponents. After placing the Zynq in the proper position, Jmio connector was placed in the
most convenient side of the board, at the bottom layer near board’s edge and close to mio
banks. With the main components placed, the remaining area was occupied by the power
stage and the passive components required by the Zynq to operate, such as capacitors,
strap resistors, filters, oscillators, LEDs. etc. The most suitable (and only) place for the
power stage was the top edge of the board.

Figure 16: OBDH power stage implemented with Cadence Allegro PCB Designer.

One of the main concerns after the power supply prototype was the heat generated, not
only by the Zynq, but the PMICs and coils as well. In order to reduce the heat transmission
between components, the first approach considered placing the power supply stage at
the bottom layer of the board, as seen in Figure 16 (pink represents bottom pads and
planes and blue the top ones). Another advantage of this solution is the slight increase of
available area for the power supply, as its main components and passives can stay closer
to the MPSoC and the DDR4 chips. Unfortunately, as the separation between OBC and
OBDH boards is only 7.9 mm and the coils measure 5.1 mm in height, the motherboard
only has 2.8 mm of available height for its components underneath OBDH power supply.
As the OBC was already designed by that time (hence difficult to modify) and had its own
power supply right under OBDH’s one, the coils and capacitors of both board collided.
We had no other option to move the regulators and their passives at the top layer (see
Figure 17). As recommended by the manufacturer and in order to reduce EMI, coils and
bulk capacitors shall be placed close to the regulators. Thanks to the use of only 3 rails
per PMIC, we could place 2 coils in one side and the last in the other side. With this
configuration and rotating the second PMIC 180o in the Z axis, we managed to fit all the
power supply at the top edge of the top layer of OBDH’s board.
Design and integration of a MP-OBC with SDR for nano-satellites 37

Figure 17: OBDH power planes in Cadence Allegro. from top to botom and left to right:
Top and bottom planes, main power plane (+5V input voltage as well as R1 and R2 rails),
second plane (R4 and R5 rails) and third plane (DDR4 termination voltage plus R3 and R6
rails).

With the components in the right place, we moved to plan the routing towards Zynq power
pins, in the center of its footprint (hence, impossible to access through the top and bottom
layers with so many signals in the perimeter of the Zynq). This power pins are accessi-
ble from any layer of the board (except form top and bottom), and thanks to the stack-up
design, there are 4 layers dedicated to power signals. As they are in the middle of the
stack-up, the output of the regulators shall make use of several vias to connect to those
internal layers in an efficient way (many vias reduce the impedance of the connection re-
ducing its losses). Every rail in the Zynq die has several pins to power (with its via), and
every PMIC’s output has also several vias. We could route each of PMIC’s vias to each
of the zynq power pins with individual thick tracks (or in a “tree” fashion), but it is a known
good practice to use planes instead. Even though the thickness and the width of the track
would allow for the required current to flow to the MPSoC with the single track architecture,
planes reduce the path’s DC resistance, reducing the losses associated with the Joule-
effect. Also, planes reduce the parasitic inductance of the connections and increase the
EMI screening. With this engineering tips we decided that all power singals would use
planes to transmit the energy required.

As you can see in the top-left image of Figure 17, several planes have been added to top
(blue) and bottom (pink) layers to connect the coils and bulk capacitors to the proper vias.
38 Design and integration of a MP-OBC with SDR for nano-satellites

Pink planes underneath the Zynq footprint correspond to filtered power rails for the internal
Analog to Digital Converter (ADC) and Phase-Locked Loop (PLL) circuitry, while the plane
around the bottom of DDR4 is used for the voltage termination required by some of its
digital signals (half the tension for the RAM controller in the MPSoC, which is 1.2 V). The
first power layer, seen in the top-left image of Figure 17, hosts the most powerful rails (R1
and R2) and the input voltage (+5V) planes due to its increased copper thickness (35 um),
which allows lower resistance per section. As the input power comes from the lateral con-
nectors and some pins of the Jmio connector, its plane have a squared shape with a void
in its center to allow the other planes to access underneath the Zynq. Our intention was to
use as many planes as possible in a single layer (to see if we could reduce the stack-up),
but the input pins from the MPSoC and the peripherals (RAMs, oscillators, VTT regulator,
etc) are distributed in such a way that not all combinations of planes are possible. After
some iterations, we came up with a solution: rails R4 and R5 together in the second power
layer (see bottom-left image of Figure 17), while R3 and R6 (or R3 2V 5 DDR V PP in the
schematic) in the third (see bottom-right image of Figure 17). In this configuration, both
DDR4 rails (R4 and R6) can have access to the RAM chips at the same time without inter-
fering with each other. As can be seen in the third power layer, close to the second DDR4
an auxiliary power plane have been added to transfer the memory’s termination voltage to
4 termination resistors and capacitors located between the two RAMs. It was the only so-
lution for connecting them to the termination line, as the location of the memory chips with
respect to the MPSoC and the Samtec connector do not allow the placement of the whole
set of termination resistors around the component (as done with the rest of them using the
pink botom plane). Also interesting to note is the R3 plane elongation along board’s left
and bottom edges. It is used by the JTAG connector, hosted in the lower-right conrner of
the board.

With this distribution of planes, we only use 3 of the 4 layers dedicated for power signals,
which will be eliminated in the near future if the power distribution tree remains as it is.
Once the planes have been disposed, the next step would be to perform a power integrity
analysis to guarantee that the MPSoC and the RAM chips receive a healthy power line
(no fluctuations in voltage levels, no hot-spots, reduced parasitic inductances, etc.). To
do so, we had to fed Cadence tools with the Input/output Buffer Information Specification
(IBIS) model of our MPSoC (to know the real electrical behavior of every pin), a theoretical
application (to know its average consumption) and the decoupling capacitors in order to
know the real fluctuations of the power line once the Zynq commutes its transistors (as
capacitors smooth the high frequency oscillations).

Unfortunately, after placing the most critical capacitors right under the FPGA footprint (in
the void between vias, produced by the “chevron-style” break-out of Zynq pins) we become
aware of an important issue to address before continuing with the design (Detailed in sec-
tion 4.2.3), hence, power integrity analysis is still under development.

As mentioned at the beginning of this chapter, the OBC was being developed while we
were still building the schematics of the OBDH, and in order to finish motherboard’s design,
Design and integration of a MP-OBC with SDR for nano-satellites 39

we had to define the pinout of the Jmio connector, the one with all the digital busses. To
properly define the distribution of signals in the connector, we could not use the schematic
design, but the layout, as the physical connections are more restrictive than logical connec-
tions (we wanted to avoid excessive intersections of signals in a given layer). By that time,
we were leveraging between Cadence and Altium, hence, without any SW tool capable
of providing a semi-automatic physical planing for the busses. Instead, it was performed
manually, on paper, with the estimate position of the components (Zynq and memories)
and connectors (please see Figure 18). The difficult task was to design the break-out of
the Zynq: routing all the signals required underneath the MPSoC. Due to the 0,8 mm pitch
BGA package nature, only one track can pass between two pins, hence, to access the
most inner pins, vias connecting to layers underneath are required. with a via for each pin,
they can be accessed from virtually any layer. Using the pinout diagram if Figure 19 left, we
started to route the most outer pins to the first possible layer N , and when no more spaces
between the them were left, the following pins would star from the layer underneath N − 1
and so on so forth. Once outside the Zynq area, we had to look for the best path without
crossing dense areas of components or higher priority signals (from the SDR and DDR4).
The Jmio pinout estimation, currently being used (see the complete schematic in appendix
E), can be seen in Figure 18. It was a very time consuming task, which yield interesting
results such as the minimum number of layers required for the busses (4, less than for the
RAM routing, hence, with margin) as well as the best position of the Jmio connector. With
pinout and positions estimations, the OBC PCB design could continue.

Figure 18: Zynq Ultrascale+ 4EG routing plan

Once Cadence was adopted, Albert Casas started by routing the DDR4 chips, as shown
in Figure 19 right. Although not shown in the image for convenience, the zone has all the
layers packed with tracks, occupying the 6 signals layers of the board. After finishing the
routing of the memory chips, Albert passed the cadence project to Carles Sierra (Cadence
environment was not set-up for parallel design), who added the required constraints for
40 Design and integration of a MP-OBC with SDR for nano-satellites

the rest of the signals and started to route some of the PMIC’s interfaces. Unfortunately,
the task could not be completed due to collisions with the buses already routed and the
stack-up, which put on hold the layout design. Further details of the issues and possible
solutions are written in section 4.2.3.

Figure 19: Zynq Ultrascale+ 4EG pin distribution (left) and DDR4 digital buses (right).

4.2.3 Results and future work

Only the issues encountered during the summer break of 2019 are written in this section
(together with some possible solutions), as the features already implemented have been
explained in previous sections of this chapter. The description of such issues will follow a
chronological order for a better reading.

At the end of July we were going to start routing the digital busses of the MPSoC, after the
constraints had been added to the Cadence constraints manager. When routing the HK
I2C bus, we realized that J2 connector was not fully accessible, as many of the layers in
front of it were occupied by the DDR4 busses. Not even the smallest via fits between any
of the bus turns, and the bottom layer is also full of decoupling capacitors and vias from
the RAM memories that block the access.

The first solution one would try uses what is called a buried via: instead of providing a
metallic hole that can connect all layers from top to the bottom, the hole would only go
from bottom to the desired layer (number 18 in this case, the closest signal layer to the
bottom). They are not typically used (if the design allows it) as they increase substantially
the manufacturing costs of the PCBs. Unfortunately, not even in this case this solution
works, as the biggest obstacle, the DQ bus (see the blue tracks in Figure 19) is placed
right underneath the connector, in the closest layer to the bottom, signal layer 18. One
option could be to swap this bus signals with the ones in another layer that do not physi-
cally interfere with the addition of a buried via to layer 18, but this solution would require a
redefinition of the the track’s widths to comply with the requirements in the new layers.

With the swapping of layers and the buried via option discarded, we looked at the manufac-
turing capabilities to see if we could reduce the diameter of our vias and fit them between
Design and integration of a MP-OBC with SDR for nano-satellites 41

the turns of the DQ bus. We corroborated that the ones being used are the smallest, from
a board of class 7, with 0.15 mm in diameter. While doing so, we discovered another
issues that affects not only to the routing of the connector, but the Zynq and memories.
Manufacturers can guarantee a minimum via diameter as long as the total board thickness
remains lower than 2 mm. In the exceptional cases in which a thicker board is required, an
aspect ratio rule applied, which corresponds to 13 in our case (class 7 board).

thickness thickness
ARLabCirc = = 13 −→ dV IA = = 0.25mm (8)
diameterV IA 13

As can be seen in equation 8, the vias being used were not compliant with manufacturers
requirements, as they where 0.1 mm too small. We created the new via and checked the
effects on the MPSoC footprint, as it has the most packed BGA (0.8 mm pitch) package.
Figure 20 shows the errors found by the automatic algorithm (red crosses) when com-
paring the constraints we had written with the real geometries of the layout. Taking into
account the increase of diameter, the surrounding ring and the clearance zone around it,
the resulting area is too big for the current state of the layout. The present tracks with a
fixed width (to control their impedance) can no longer be used as they do not fit between
the new vias. Reducing their width would increase their impedance, worsen the signal
integrity and forcing the ddr4 to work at slower frequency.

Figure 20: Image of Cadence Allegro PCB designer of the Zynq footprint (blue circles)
with the vias required by the manufacturer (big ones) and the ones currently implemented
(small ones).

In this situation, seems like the only option left is to revise the stack-up design and search
for better dielectrics that require less thickness to operate, and reduce the layer count, if
possible. In this regard, the MPSoC power supply design was accomplished without the
use of all power planes, hence, layer 10 and its associated dielectric can be removed. This
problem will be addressed in future revisions of the PCB with the whole team.
42 Design and integration of a MP-OBC with SDR for nano-satellites

5 System interfaces

The C3 SatP system is conceived as a powerful computer for nano-satellites, with special
attention to the CubeSat standard. Hence, one of the requirements is to be compatible
with commercial structures and electronics. Also, as the computer is composed of several
PCBs, some care must be taken when designing their electrical and mechanical internal
interfaces, specially, considering the nature of its environment.

This section explains the design process of both types of connections: the ones towards
CubeSat structures and subsystems and the ones between C3 SatP boards

5.1 External Interfaces

One of the first constraints required to start the electronics design of the computer was the
available space inside a CubeSat and the mechanisms to hold all electronics. We looked at
mechanical drawings of commercial structures from the main companies (GOMspacespace,
ISIS and Pumpkin) to see how the electronics are stowed inside, since the standard only
defines external mechanical interfaces. In general, PCBs are attached to the structure by
a metallic rod (see Figure 21 left), in a similar way stackable electronics do: with metallic
spacers. Providing a hole at each corner of our motherboard with the proper diameter
and separation seemed sufficient to hold to the external structure and survive the launch.
Searching for the details of the holes distribution, we discovered that no company offers
the same configuration. We defined three different hole distributions, superposed in the
Computer Aided Design (CAD) image of Figure 21 right. Only one set of holes will be im-
plemented at each mission/version to avoid unwanted mechanical stresses at the corners,
but in this sense, our electronics are hence compatible with 3 commercial structures: ISIS,
GOMspace and Pumpkin.

Figure 21: CubeSat Structure with its spacers for PCBs (left) and first C3 SatP CAD version
with the holes to interface any commercial structure

Compatibility with electrical interfaces (and mechanical, considering connectors) of other

commercial subsystems was also a driving requirement for our designs, but that meant
implementing the PC104 in our boards (please see Figure 22 a), an inefficient way to
connect to other subsystems (no standard, almost no pins shared between commercial
subsystems, not suitable for high speed communications, etc) which also reduces the
amount of available space for our electronics (around 10% less area). We later realized
that almost all PLM instruments in CubeSats have a custom I/F towards their OBC, and
Design and integration of a MP-OBC with SDR for nano-satellites 43

many chose to route it with other means (high speed connectors or harness), thus the use
of the PC104 is not mandatory.

Figure 22: From left to right: (a) PC104 at the lower-right corner of the PCB, (b) Molex
PicoLock connector, (c) Amphenol SMPM connector, (d) Molex PicoBlade connector and
(e) Samtec LSHM connector.

We finally decided to remove the connector completely, and add as many Molex PicoBlade
connectors (see Figure 22 d) as digital buses we want to provide to the rest of the satellite
(see the connectors and busses offered in Figure 2). Needles to say, power and RF signals
will also have their dedicated connectors. A 6-pin PicoLock Molex connector to power the
boards (see Figure 22 b) and an Amphenol coaxial connector (see Figure 22 c) for the
different RF singals.

5.2 Internal Interfaces

As can be seen in Figure 23, system boards will be distributed in an stackable fashion,
with the master OBC in the middle, the OBDH on top and the SDR underneath (from the
OBC’s perspective). Information will be shared between them thanks to a set of stackable
connectors, the long ones at the lower-right side and upper-left side of all boards (some
are hidden by the PCB). Although having a very strong mating force, other means should
be provided to the boards to increase the global tolerance to mechanical stress, specially
considering the nature of the the launch environment. In this regard, a hole has been
added to each of the corners of the daughterboards, to connect them mechanically to the
OBC with screws. Holes position in all boards (with respect to stackable connectors) are
shared so the screw can cross from one daughterboard to the other, exerting a compres-
sion force in the motherboard. Unfortunately, in this situation most of the stress would still
be in the Samtec connectors.

Figure 23: C3SatP boards with their reference (left) and OBC blueprint (right). Frame’s
color represents subsystem connection: Blue ones connected to OBDH, red ones to OBC
and yellow ones to the SDR.
44 Design and integration of a MP-OBC with SDR for nano-satellites

To relief some of the stress due to the compression of the daughterboard’s screws and
generated from the launch (and also due to other reasons, please see section 6), several
mechanical structures have been developed (see the metallic pieces right on top and un-
der OBC’s PCB in Figure 25). For more information regarding the mechanical design of
the different metallic boxes please see section 6.

As the system uses many high speed signals shared between them, we looked for a more
suitable connector than the PC104 to stack the PCBs. The new connector should have
plenty of pins (for the high number of digital busses going through it), capable of trans-
mitting power and high speed signals (mainly for the SDR LVDS signals), with good me-
chanical resilience once mated. After searching connectors in Molex, Samtec and Hirose,
we finally chose the Samtec LSHM-150-04.0-L-DV-A-S-K-TR, a 100-pin hermaphroditic
shielded connector for board to board I/F (see Figure 22 f ).

With so many connectors, pins and boards, we had to find a safe procedure to map all
connections of the different Samtec of the system. With it, future changes of the HW
in any PCB would be easily tracked to the affected pins in other boards to update them
accordingly. One must think that for an electronic engineer and its design SW, it is easier
if the required signals to be routed are ordered in the connectors reference system. In a
schematic, connector’s symbols always have the same shape and pin distribution, despite
the real orientation of the connector (on top, or bottom, for example). In order to reduce
the risk of human error when building the schematics of different systems, we must find
a simple but reliable way of generating the said mappings. The following sections explain
the details of each I/F, and how to produce the pinout of the connector at the other side.
In this regard, we define the footprint pin’s numbering in the same reference frame as the
OBC: looking from above the PCB, the layout would form a 2x100 pins matrix, with the
long side along Y axis.

5.2.1 SDR-OBC connection

The SDR subsystem shall be connected to the OBDH through the OBC’s connectors and
PCB. As it was one of the first systems to be developed, its pinouts where defined first, so
the following connections will be explained in this direction.

Defining a set of pins for a given connector of the SDR PCB (S) and its companion in the
bottom part of the OBC (Mb ) in equation 9.

   
s s2 mb mb2
 1   1 
   
 s3 s4   mb3 mb4 
 . ..   . .. 
   
S =  .. .  Mb =  .. .  (9)
   
   
s97 s98  mb97 mb98 
   
s99 s100 mb99 mb100
Design and integration of a MP-OBC with SDR for nano-satellites 45

We can find a relationship between them once mated. A simple way to understand it is by
choosing one connector (with its pinout) and perform the required rotations to end up in
the position of the companion. If we take the SDR connector as fixed, the other pinout will
be defined by rotating 180o in the Y axis, or with a rotations of 180o the in the two other
axis. As can be seen from the results of equation 10, SDR signals have basically swapped
columns in the bottom footprint of the OBC (from the connector’s perspective).

 
s2 s1
 
 
 s3 s4 
 .. .. 
 
Mb = S · Ry (π) = S · Rx (π) · Rz (π) =  . .  (10)
 
 
 s98 s97 
 
s100 s99

5.2.2 OBCbotom-OBCtop connection

In order to simplify the routing, save space as well as because almost all signals from the
SDR will be connected to OBDH’s MPSoC (crossing OBC’s PCB), we opted for placing
two connectors on the top layer (J6 and J17) exactly above the ones that connects to
the SDR at the bottom (J19 and j20, please see Figure 23). In this configurations, each
pin bellow would connect to a pin in the connector on top thanks to a Vertical Interconnect
Access (VIA) in front, saving space and routing efforts. As the OBDH was being developed
at slower pace (hence has lower priority in terms of pinout definition) and because it has
many layers to help in the routing process, we “moved” the routing issues to OBDH’s PCB.
This time, the rotation required to map both pinouts can not be the same as in the previous
interface: it is not a connector to connector matching, but two independent connectors
routed vertically, and also because we wanted to match shield’s mounting hole of bottom
and top connectors. Still, it can be defined a set of pins for a given connector at the top
(Mt ) and another set fot the bottom one (Mb ) as in equation 11.

     
mt mt2 mb mb2 s s1
 1   1   2 
     
 mt3 mt4   mb3 mb4   s3 s4 
 . ..   . ..   .. .. 
     
Mt =  .. .  Mb =  .. . = . .  (11)
     
     
mt97 mt98  mb97 mb98   s98 s97 
     
mt99 mt100 mb99 mb100 s100 s99
46 Design and integration of a MP-OBC with SDR for nano-satellites

Following the same method as in the previous interface and applying instead a 180o in the
x axis, we can find a relationship between Mb and Mt (see equation 12). As can be seen
from the results, bottom signals have swapped rows in the top footprint, and if compared
with SDR ones, both rows and columns have been swapped (always from the connector’s
point of view).

   
mb mb100 s s
 99   100 99 
   
mb97 mb98   s98 s97 
 . ..   .. .. 
   
Mt = Mb · Rx (π) = Mb · Ry (π) · Rz (π) =  .. .  =  . .  (12)
   
   
 mb3 mb4   s3 s4 
   
mb1 mb2 s2 s1

5.2.3 OBC-OBDH connection

In this case, as in the SDR-OBC interface (section 5.2.1), the rotation required to map the
pins of J15, J16 and J17 (Mt ) to Jmio, J1 and J2 (O) is again in the Y axis (see equations
13 and 15). As a result, top connector’s signals have swapped columns in OBDH’s con-
nector footprints (from connector’s perspective). Comparing the result with SDR’s original
footprints, we can see that only rows have swapped. Indeed, two 180o rotations in the Y
axis along OBC’s interfaces do not produce any change, leaving the only rotation in X axis.

    
o1 o2 mt1 mt2 s100 s99
     
     
 o3 o4   mt3 mt4   s98 s97 
 .. ..   . ..   .. .. 
     
O= . .  Mt =  .. . = . .  (13)
     
     
o97 o98  mt97 mt98 s s4 
  3
 
   
o99 o100 mt99 mt100 s2 s1

O = Mt · Ry (π) = (Mb · Rx (π)) · Ry (π) = ((S · Ry (π)) · Rx (π)) · Ry (π) = S · Rx (π) (14)
Design and integration of a MP-OBC with SDR for nano-satellites 47

   
mt mt1 s s
 2   99 100 
   
 mt4 mt3  s97 s98 
 . ..   .. .. 
   
O = Mt · Ry (π) =  .. .  = S · Rx (π) =  . .  (15)
   
   
 mt98 mt97   s4 s3 
   
mt100 mt99 s1 s2
48 Design and integration of a MP-OBC with SDR for nano-satellites

6 System structures

Many CubeSat subsystems rely on PCB’s tensile strength as the only structural support
for their components and instruments. Indeed it is sufficient for launch and space survival
from a mechanical point of view, but many times structural elements also play an important
role in other aspects of our electronics, such as thermal control, radiation protection and
EMI shielding. With the objective to mitigate this issues, the C3 SatP team decided that
some structural aid would be required. The design of the structural elements under the su-
pervision of the author of this work and carried out in part by Carlos Mansanet and Agustı́
Carrillo, will be presented in this section. In this regard, while Mansanet and Carrillo were
responsible of developing the low level CAD design and simulations, the author served as
the bridge between them and the electronics and thermal engineers of the team, while vali-
dating the integration of all the pieces of the computer. As clarification, Mansanet provided
the first version of the C3 SatP structural elements (see Figure 21 right), while Carrillo mod-
ified it following the electronics evolution and simulated the result (see Figure 25), in order
to present his work as a final degree thesis [34] at UPC (“Disseny i desenvolupament de
la estructura mecànica de l’ordinador a bord del CubeSat C3SatP” [34]). Thanks to them
Carles Sierra, was able to learn the basics of Autodesk Inventor to generate mechanical
CADs and used that knowledge to develop and modify several structural elements for the
CubeSat model used in the outreach campaigns (see section 7).

6.1 Requirements

CubeSat structures must comply with several requirements imposed by the electronics
in order to survive the harsh environments during the mission. Launch and LEO envi-
ronments are inherently hostile for COTS electronics, hence, several protections shall be
provided, tailored for the specific nature of the electronics and the mission. In our case,
some challenges were raised at the beginning of the high-level system design, mainly due
to the MPSoC and the SDR. Mechanical resilience was not a big concern at that time
since many past CubeSat missions were successful with only the PCBs as internal struc-
tures. Hence, it was not the driving requirement for the design. Instead, Radiation and EMI
shielding, with special attention to thermal dissipation, were considered more problematic.

The typical approaches to mitigate radiation effects on electronics are the use of radiation
tolerant components or increase the inherent mass of the cage that hosts the boards. As
the electronics must be COTS, the option is to provide some sort of metallic box around
them with enough thickness to guarantee a minimum ionizing radiation inside. EMI radia-
tion from the SDR or high speed digital buses can also be mitigated using a metallic box
properly connected to a common ground, like a Faraday cage.

Heat generated by the most powerful electronics have been a concern since we estimated
the currents required by the Zynq. It is specially critical in space as there is no cooling by
convection due to the free-fall the satellite is experiencing and the absence of atmosphere.
Design and integration of a MP-OBC with SDR for nano-satellites 49

The most efficient way to extract this heat is by conduction, but PCBs show anisotropic
behaviours (due to its layered assembly) and usually have a high thermal resistance in
their normal axis. In this situation, heat pipes could aid reducing the thermal resistance
towards the heat sink of the satellite. With an estimation of 4 W for the Zynq and 1 W for
the SDR chip, we had to design a way of extracting this heat and relief the PCB of both
daughterboards from their heat flow which would increase several degrees the nominal
temperature of other components in the system.

All this challenges seems to point out to an interesting solution worth studding: encap-
sulating both subsystems, the OBDH and the SDR, with thick metallic elements. Also,
this elements could improve the system’s resilience to the launch phase. More detailed
information regarding the challenges of the design can be seen in Agustı́ Carrillo’s work
[34].

6.2 Mechanical Design

By the time the team decided to develop some structural elements to improve the system’s
resilience to the space environment, we only had a rough estimation of the distributions
of the boards, connectors and mechanical interfaces towards commercial CubeSat struc-
tures, not to mention board geometries and thickness (please see Figure 21 right). Even
though, it helped consolidating the core ideas of our approach when presenting our sys-
tem to conferences or workshops. Carles Sierra was able understand system’s mechanical
requirements in order to coordinate all the actors involved in the mechanical design, serv-
ing as a communication node for the engineers scattered around ICE-CSIC, ICC and the
UPC. With this in mind, this section will skip the specific details of the mechanical design
of the CAD models and their simulations, as they are already gathered in Agustı́’s report
[34]. Instead, the section will focus on the main characteristics of the elements, and the
reasons behind them due to the interaction of several engineers of the team.

The first structures to be designed were the SDR ones using Autodesk Inventor 2015. A
metallic box for the top side and metallic walls between the SDR and the OBC (please see
Figure 23). In the top box, a plateu that will serve as heat sink for the SDR transceiver was
implemented. The lateral walls of the top box of the SDR were adjusted so that they could
fit between the coaxial connectors and make contact with them. They were conceived to
make physical contact with a frame provided in the board’s edge which is stitched with vias
connected to boards ground planes. With this solution we ensure a good electrical connec-
tion for the EMI shielding while we try to reduce the thermal resistance of the PCB in the
vertical axis with the metallic vias going from top to bottom. The intermediate structure be-
tween SDR and OBC serves the same purpose, allowing more heat to be dumped towards
the OBC while protecting from possible EMI and increasing mechanical resilience.
50 Design and integration of a MP-OBC with SDR for nano-satellites

Figure 24: SDR PLA 3D printed structural elements with an Ag+Cu coating.

Once the OBC design was finished, the integration of its CAD model with the SDR and
its pieces was checked for any collisions. Some of the walls where touching components,
connectors and some unwanted vias from the motherboard. Providing some arcs to avoid
these areas, the design was considered mature enough. Both structural elements were
used to test the performance of a refurbished CNC milling machine at the ICC with unfruit-
ful results. While OBDH’s structures were being designed, SDR’s ones were manufactured
with a PLA 3D printer to check for unexpected collisions an the suitability of the thermal
sink “plateau” with successful results (please see Figure 24). To emulate some of the
metallic properties that the final structure would have, a conductive coating (sprayed var-
nish with silver and copper particles) to the printed elements was applied in one of the
chemistry labs of the UB, as can be seen in Figure 24. Thanks to it, the EMI tests have
started, although they are still in progress.

As mentioned in other sections, OBDH design was behind schedule, and because we were
not confident with the 3D modeling of Cadence tools, the previous methodology could not
be applied in this case. Instead, once the stack-up and the position of the main com-
ponents were defined, we created a CAD model of the PCB to use as template for the
integration of the system and the development of its enclosures (see the top board of 25).
By that time, power supply was resting underneath and the Samtec connector on top of
OBDH (J3) was still not present, hence the geometry of the top box was similar to the SDR
one: a metallic cover with a heat sink plateau for the MPSoC, with its wall in contact with
the stitched frame and without any opening for connectors (except for the Samtec ones).
The element between OBDH and OBC follows the same logic as in the SDR-OBC inter-
face, but without a layer separating both boards as the bulck components of the OBC’s
power supply are only separated around 2 mm fron the OBDH bottom side (see the struc-
ture on top of OBC board in Figure 25 left).

Following the evolution of the electronic design, J3 Samtec connector was added to the
3D model. An indent was provided at the top box to allow a custom PCB with a Samtec
Design and integration of a MP-OBC with SDR for nano-satellites 51

connector (interfacing a high-speed harness) to be connected to the OBDH safely using

the its screws as fasteners. Room was also made for the coils of the power supply which
have moved to the top layer, by increasing several millimeters the overall height of the
box. With this last modifications, we printed the model and the structural elements with
successful results. Once the mechanical design was considered finished (at least until
new changes in the OBDH arises), Agustı́ performed several simulations to validate the
survival of the computer in the launch environments of several rockets (Ariane 5, Soyuz
and Falcon 9). Thermal simulations of a simplified version of the integration in Figure 25
have been also performed, thanks to Manuel Carmona. The results of this simulations and
possible future modifications are commented in the following section.

Figure 25: C3SatP computer explosion with its aluminum boxes.

6.3 Results and future work

With the current state of the computer hardware as defined in the Figure 25, several sim-
ulations and tests are ongoing in order to validate our designs. It is true indeed that the
OBDH will most surely suffer modifications due to the issues found during its routing, but
we are confident to say this changes would not severely modify structure’s geometry. The
first results from a mechanical point of view can be found in Agustı́’s thesis [34], which
showed a maximum deformation of around 40 µm in OBC PCB’s center, as it withstands
all the load from the computer’s boards and structures during the launch. Vibration and
noise simulations are expected to be simulated in the following months.

Thermal simulations showed more concerning results. Even though not accurate when it
comes to absolute temperature values of each element (too many uncertainties, such as,
for example, the real CubeSat internal structure), one can see the hot and cold spots in
the system and the gradients they produce in Figure 26. From the results of the simulation
in a static regime, it is clear that the heat generated in the OBDH is not properly dissipated
due radiation and transmission to the other boards. The color code shows a temperature
52 Design and integration of a MP-OBC with SDR for nano-satellites

difference of around 10 K between them which points out to a bad thermal link between
OBDH and OBC. Thermal sink added in the internal face of the top box (to help in the
MPSoC heat dissipation) seems to work as expected: thermal gradients between the PCB
and Zynq are negligible. Similar behaviour is observed in the SDR board. The unexpected
and thus worrying result from the simulation is related with the DDR4 chips. It turns out, the
selected model for the RAMs is encapsulated in a package with a high thermal resistance
in its interface with the PCB, which increases their temperature as they do not have a direct
contact with the metallic box as in the case of Zynq.

Figure 26: Simplified CAD model (left) used in the thermal simulations of the C3 SatP
computer (right). Courtesy of Manuel Carmona.

Changes in the geometry of the structural elements (to mitigate the issues found so far
and to improve the overall reliability) are expected in the future, although not considered
top priority right now since the OBDH design is still open. Once finished, the top enclosure
will be refurbished to account for new connector positions and to provide a thermal sink to
the memories, similar to the one used for the MPSoC and the SDR transceiver. To reduce
the thermal gradient between boards, we are considering to increase the diameter of the
internal screws and allow more heat flux to flow towards the OBC. Another option would
be to provide some physical connection between the top box and the external mounting
holes, acting as a heat pipe and bypassing the OBC’s PCB.

This possible modifications are on hold until a new person joins the team and takes the
role of mechanical engineer to implement the changes using the CAD SW. In less than
a year we expect to have new additions to the team, finish the electronic and mechanical
development, integrate the first prototype of the complete system and test its behaviour in
the Nano-Sat Lab testing facilities at UPC campus Nord [11].
Design and integration of a MP-OBC with SDR for nano-satellites 53

7 Outreach

The different outreach campaigns in which Carles Sierra have contributed to, are presented
in this section. As a research institution, we are always looking for different ways to share
our knowledge, and if possible, learn and increase our network of contacts. Conferences
pose a good opportunity for this task, specially if their topics are related with CubeSats or
space engineering. Even though not so profitable (in the short run), we are also willing
to teach our field of study to a wider audience, either with a set of keynotes, stands or
workshops.

7.1 Second Barcelona Technoweek Week

During July 2017, the ICC organized the Second Barcelona Techno Week [35], this time
with the nano-satellites topic. From its webpage: “Barcelona Techno weeks are a series of
meeting point events between academia and industry, organised around a technological
topic of interest for both worlds. [...] The second ICC technoweek will be devoted to the
emerging field of nano-satellites, [...] an intensive 5-day “bootcamp”, providing: Keynotes,
classes, poster sessions and workshops”.

By that time, the C3 SatP project was in its infancy, so the team took advantage of the
opportunity and showed their area of expertise in past projects as a set of talks, while
the author of this thesis participated in the workshop as attendant. Arranged in small
teams, we competed for the best designed CubeSat mission. Our mission MATE (Mars
Aerobreaking Technology Experiment) was the most ambitious project: an inflatable heat-
shield demonstrator in Mars atmosphere (please see Figure 27).

Figure 27: MATE mission renderings

7.2 Sonar+D workshop and MakerFaire

During July 2018, the music festival Sonar was being held in Barcelona. As it was started
in 1993, Sonar wanted to make something special for this year’s edition, and it involved
many actors from the IEEC. Ingasi Ribas, famous planet hunter [36] and current Director of
the IEEC together with Doug Vakoch, President of the METI (Messaging Extra-Terrestrial
Intelligence) partnered with them to send music from 38 artists to the stars [37]. Using the
radio antenna in EISCAT, Norway, Vakoch and his team sent the 38 musical pieces and
54 Design and integration of a MP-OBC with SDR for nano-satellites

relevant information about the human race towards Luyten’s Star, at 12.4 lightyears away,
in an attempt to make the first contact with a possible intelligent lifeform in the possibly
habitable Luyten b [38]. If “Luytonians” are capable and decide to answer, it will coincide
with the 50 anniversary of Sonar, in 25 years.

Thanks to this partnership and the topic selected, we had the opportunity to show the state
of the art of space engineering by organising a workshop [39] in the Sonar+D, the alterna-
tive festival of developers, designers, inventors and entrepreneurs who work in the musical
sector [40]. As nano-satellites where gaining reputation and offered a much relaxed ap-
proach when explaining space systems design, our team was the most suitable one in
the IEEC’s repertoire to perform the workshop. By the same time, a similar event was
taking place in Barcelona, the Maker Faire: a fair of inventors, tinkerers and DIY projects.
As we were also invited and both events happened in a short time-span, the team de-
cided to participate as well in Maker Faire with a stand to showcase our technologies and
discoveries.

Figure 28: Pictures of the Sonar+D workshop.

Apart from the usual project meetings every 2 Fridays, a “sub-team” of engineers was
assembled (from the project but also with the addition of Carles Araguz from the NanoSat
Lab and Ismael Benito from the UB) which performed regular meetings every week for
more than 2 months to prepare the materials for the workshop and the stand. Several ideas
where considered in the first brainstorming: mission planing competition, system design
of a given mission, emulating a ground control, etc. After some iterations with Sonar
organizers regarding the available space, resources and security measures, the idea of
developing a two phase event in Sonar+D took shape. We would first show the CubeSat
concept and let the assistants perform some kind of integration and test of a model, and
the second part we would then “simulate” the launch, commissioning and operation phases
with a helium balloon and one of this models. To save resources (development time and
costs) and better advertise the IEEC, we opted for using the balloon and the model to
showcase the engineering capabilities of the institute in the Maker Faire stand.
Design and integration of a MP-OBC with SDR for nano-satellites 55

Figure 29: Pictures of the CubeSat designed for the Sonar+D workshop

We wanted to give a hands-on experience to the assistants while teaching to them the
main parts of a satellite, how to communicate with them and how to perform some oper-
ations in-orbit. With this in mind, we designed a simple CubeSat structure that hosted a
Raspberry Pi 0 inside, with 802.11n wireless LAN as communication link, some sensors
to read and a small camera (please see Figure 29). we adapted a simple CAD model from
Thingiverse [41] to fit our needs (simple to assemble in less than an hour). The ribs of
the structure were printed using different 3D printers in UPC, UB, and ICE-CSIC, while
the lateral and superior panels were laser-cut by an specialized workshop in Barcelona.
C.Araguz and Ll.Gesa developed the communications system and set up a web page that
served as ground station console for sending commands and receive telemetry from the
Raspberry.

Sonar organizers confirmed the assistance of 25 people to our event. We did not have
enough budget for so many models, so we decided to form teams of 5 and just develop 5
CubeSats for them to assemble and control in the workshop. The assistants had to pay a
small amount to have a place in the event, and we used that money to give them a present.
It was not enough to buy the complete CubeSat model used by the teams (∼ 60 e), but
sufficient for a set of ribs, panels and screws to assemble the structure in their homes. The
instructions of its integration, the details of the electronics and the CAD models are easily
accessible in a Github repository [42] thanks to Carles Araguz, in order for the assistants
to replicate the whole satellite at their pace.

Our idea was to do the second part outdoors, so the balloon could ascend to a good
position to see the whole festival and let the assistants control the 16x16 RGB LED screen
and generate some light patterns. Safety reasons prevented from doing it so, and we
looked for the best place to perform the ascent in the fairgrounds of Sonar+D. As can
be seen in the left picture of Figure 30, a big stair hole in one of the domes of La Fira
de Barcelona was the place for the performance. At the same time there was prepared
a portable ground station next to the balloon so any assistant could see different data
56 Design and integration of a MP-OBC with SDR for nano-satellites

gathered (altitude, orientation, humidity, etc) and a video streaming of the stair hole and
themselves (see right picture of Figure 30).

Figure 30: Pictures of the “launched” CubeSat (left) and the telemetry received from its
camera and sensors (right).

Carles Sierra was the responsible for the design and procurement of some the structural
elements of CubeSat model as well as the balloon and its anchorings. Thanks to the me-
chanical CAD knowledge learned from ICE-CSIC, two internal interfaces were developed
to physically connect the Raspberry pi electronic board to the external structure, similar
to the OBC PCB. One version would only have the required holes to screw everything to-
gether (used in the workshop models), but the other would also have a hole to attach a
panel mount switch (to simulate the typical “remove before flight” pin) and a slot to host
a USB battery (only used in the balloon phase). The top anchoring was also designed
from scratch using Autodesk Inventor. A pyramid-shaped structure with simple holes in its
apex was sufficient to withstand the weight of the CubeSat model. The second version re-
moved some material from the pyramid that was not performing structural work, reducing
the mass while maintaining performance. All structures designed were printed with a PLA
3D printer at ICE-CSIC laboratories. The balloons available where checked in a profes-
sional distributor of latex balloons for atmospheric probes [43] and selected the one that
could hold enough helium to sustain the CubeSat model plus a safety margin to account
for the helium leaks during the second phase and to increase the tension of the anchoring
wire and reduce the drift due possible wind currents in the dome. A 300 gram balloon with
a capacity of 15m3 was more than enough for our needs. With the remaining budget we
bought a tank of 3.6m3 of helium to the company Linde and a valve to fill the balloon with
minimum leakage.

Thanks to the hard work and hours of dedication by the team and collaborators, the work-
shop and the launch simulation where highly praised, not only by the assistants but also
from Sonar+D staff. Many journalists came asking for interviews for their radio programs,
TV channels and newspapers, which was the perfect opportunity to show the work being
done in Barcelona in the nano-satellite emerging sector [44].
Design and integration of a MP-OBC with SDR for nano-satellites 57

Figure 31: Pictures of the Maker Faire stand.

Right after the Sonar+D event we moved the balloon to the Maker Faire fairgrounds, next
to the Fira de Barcelona. We left there the balloon filled with helium (we did not have a
pump to refill the tank) and prepared the stand for the weekend, as can be seen in the
pictures of Figure 31. This time, the event targeted a wider audience, which reacted very
favourable to our CubeSat models and explanations of the space technology sector.

The experience of developing such events was so profitable, the team behind it is willing to
organise more events with a similar workshop, as we still have all the materials to replicate
the one in Sonar+D.

7.3 Second Open Source CubeSat Workshop

In september 2018, the second edition of the Open Source CubeSat Workshop was held
in ESAC, Madrid [45]. Lluı́s Gesa and Carles Sierra went to present the C3 SatP computers
and to probe the Open Source market in CubeSat community (see Fitgure 32). The poster
presented can be seen in Appendix D.

Many interesting talks were held, from companies offering development kits and subsys-
tems to amateurs showing their ground station projects and systems. One of the most
interesting ones was given by a teenagers, Julian Fernandez, who already developed his
first “pocket-sat”, a 5x5x5 cm satellite, with everything required: Batteries and EPS with
deployable solar panels, LoRa transceiver with deployable antennas and an OBC based
on ATMEGA family microprocessors. Fosa Systems and its pocket-cube, FossaSat, looks
very promising [46]. Institutions like Satelogic and Satellio were very interested in our sys-
tem, and we established a communication path with them for future collaborations once
we have fully developed and tested our computer.
58 Design and integration of a MP-OBC with SDR for nano-satellites

Figure 32: Picture of the OSCW assistants.

Design and integration of a MP-OBC with SDR for nano-satellites 59

8 Conclusions

The overall current results of the project, even though it is still ongoing, are discussed in
this section. Both team and personal achieved goals are commented, as well as the ones
not reached by either unexpected issues, lack of engineers or simply lack of time. The
future tasks to be performed to achieve the said objectives will also be commented, as well
as the long term expectations of the project and the future applications of our computer.
Each individual objective will be referenced with “ID” number, which corresponds to the
numbering in the list of objectives, in section 1.1.

8.1 Thesis objectives achieved

From the goals list of section 1.1, the author is confident to say that all objectives have
been accomplished, except for the third, the development of the OBDH.

Carles Sierra has been actively involved in the system design meetings held every 2 Fri-
days, giving the status of his tasks and discussing the high level options with the other
engineers (TO-1). In many occasion he provided key solutions for the proper integration of
the computer, trying to take advantage of the synergies of the system.

Also, from the conception of the project until now, Carles Sierra has filled the role of me-
chanical engineer at system level. With his background in electronics and pursuing his
Master’s degree in aerospace engineering, he was the most suitable asset from the avail-
able engineers of the team, at the beginning of the project. It is true indeed that IEEC has
several mechanical engineers better suited for the task, but usually they are working ex-
clusively for other missions and did not have the time (nor the permission) to work with the
C3 SatP team. The author was able to gather and understand the mechanical requirements
of the system during Friday meetings and transmit them to the mechanical engineers will-
ing to help. When Agustı́ came to pursue his final degree thesis, Carles became his tutor,
teaching him all the knowledge learned from from the team and the main ideas behind the
design. From that moment until now, Carles Sierra became the main communication chan-
nel amongst the engineers affecting or being affected by mechanical decisions. Objective
TO-5 is, hence, achieved.

The power supply design has also been successful (TO-2), assuming that the prototype
developed is sufficient to validate our approach in the final implementation in OBDH board.
Electrical interfaces have been defined without any unexpected issues as well (so far):
SDR board successfully controlled with an external FPGA and communication with the
OBC using any of the available digital buses achieved, which validates the different pinouts.
Mechanical connections (mounting holes and stackable connectors) also showed no is-
sues whatsoever, hence, we can consider TO-4 accomplished as well. As the project had
a short budget, one of our concerns was to secure funding, hence, we attended several
60 Design and integration of a MP-OBC with SDR for nano-satellites

conferences to extend our network, to show our product, and to look for possible collab-
orations in the future. Also, because of the nature of IEEC (a non-profit scientific private
foundation), we were also involved in the conception, design and executions of some work-
shops related with CubeSats. Specifically, the author attended the Open-Source CubeSat
Workshop in ESAC, the Second Barcelona Technoweek, and has been one of the promot-
ers of Sonar+D and MakerFare workshops, achieving TO-6.

8.2 Thesis objectives not reached

As mentioned, OT-3 has not been achieved, as the OBDH is still under development.
Analyzing the reasons behind the delays and issues encountered we can learn valuable
lessons and avoid (or mitigate) the same mistakes in the future.

When planing and sharing the work packages, there was an underestimation of the de-
velopment costs of such a complex system and an overestimation of the engineering ca-
pabilities. The deadlines where tight, but achievable, if it was not for the constant issues
with Cadence, its tools and floating licenses. Choosing the cheap option is not always the
cheapest solution at a longer term. With constant random crashes, loading times of 15
minutes (due to licence’s server issues), and the steep learning curve of its scattered SW
tools, makes Cadence one of the most cumbersome applications with which to develop
electronics (in the author’s humble opinion). The decision to not set up the Team Designer
environment (to work in parallel) was also inadequate, as would have allowed to speed up
the design by dedicating more engineers to that task.

8.3 Project goals status

As per September 2019, the complete computer is still not fully developed, hence, not all
the team goals have been reached. Specifically, objectives PO-3, 5, 6 and 7 are still open
due to several reasons. PO-3 had serious delays due to the steep learning curve and
sequential design nature of Cadence tools, coupled with the fact that OBDH is the most
complex subsystem. Structural element’s design for PO-5 could be considered done, but
after the thermal simulations, we expect to perform some more updates in the near future
to increase its resilience to the space environment. The SW and firmware architecture for
the subsystems and components (PO-6 and PO-7) is being developed right now, with 3
full-time and 3 partial-time engineers. The simple reason for this delay has been the lack
of hardware to program. Software engineers in the team took the role of advisors at the
early stages of the project while waiting for the electronic engineers to deliver the boards.

Although the project is no finished (and some tests are still to be performed), the rest of
team objectives can be considered achieved. The electro-mechanical interfaces (PO-4),
SDR (PO-2) and OBC (PO-1) boards have been defined and developed. We attended to
several conferences and workshops to show our system (PO-9), which yield many new
Design and integration of a MP-OBC with SDR for nano-satellites 61

contacts in the sector (Open Cosmos, Libre Space Foundation, Satellogic, Pangea, Sate-
lio, Cadiz University, SatNOGS, etc). Project managers secured future fundings with the
“Call-to-Orbit” project with ESA and Open Cosmos [47], started a collaboration with the
Cadiz University and their “fly your satellite” ESA project [48], as well as found possible
clients for our system such as SatelIO, or Satellogic.

The overall feeling is that the project is advancing in the right direction, although at a slow
pace. A faster development would be possible if all the team members would focus their
efforts in this project, instead of being part of 2 or 3 different missions. As you can imagine,
the IEEC is involved in big ESA missions, which are more important and thus top priority
for the team members (including the author of this thesis, which is involved in ARIEL [4]
and LISA [3] as well). Also, the lack of key positions in the team, such as a mechanical or
aeronautical engineers, forces other team members to do their jobs, adding workload that
distracts them from the tasks they are experts of.

8.4 Future Work

The next steps to finish this phase of the project are clearly finishing the OBDH design,
manufacture the structural elements, integrate the system, develop the SW architecture
and test the computer in the NanoSat Lab. After some iterations improving and correcting
the issues found in the testing campaign, the first operative version will be finished, which
would open more options of collaboration, fundings and even launch opportunities.

Even if the first functional version of the C3 SatP computer passes all the tests, is still has
only a TRL between 6 and 7. To get the distinction of “flight-proven” system (TRL 9),
hence, defined as a reliable computer to use in space, the last test must be performed
out of the atmosphere, at least in a LEO orbit. The middle-term future prevision is thus
finding a mission (in collaboration or ourselves) in which to install our system, and test its
performance in space while doing non-critical mission tasks. Once we acquire the TRL 9
status, interested companies (Satelio, Satellogic and others) would start trusting our prod-
uct (and our expertise) and might look for funded collaborations and/or hire our services.
As a matter of fact, we are currently exploring two interesting options in this regard: an
oportunity to fly our stand-alone version of the OBC in a CubeSat mission, and possibility
to fly our complete system in our own mission.

At the beginnings of 2019 an opportunity came from the University of Cadiz thanks to the
contact of a former IEEC engineer who worked there in the past. The university won the
fly your satellite competition [48] and we could provide them with a CubeSat computer,
at reduced cost. Their mission would not require the powerful OBDH nor the SDR, but a
reliable computer to control the CubeSat. Thanks to the modularity of our system, we sent
the schematics and PCB layout of the stand-alone version of the OBC so they could start
manufacturing and testing the HW. In the following months the SW architecture would be
finished and sent to them for further testings and hopefully, in one year, increase our TRL
62 Design and integration of a MP-OBC with SDR for nano-satellites

with a successful mission.

The second opportunity to increase our TRL came by the end of August 2019, when
Open Cosmos gave a positive answer to our proposal for the “Call to Orbit” mission called
4DCube (Debris Detection at Dawn and Dusk CubeSat) [49], giving us an excellent oppor-
tunity to increase the TRL our our computer. The project will start in the following months
and we are certain that our system will be finished before the end on January, giving us
room for testing and validating before the launch (date still to be determined).

The long-term prevision for the computer is uncertain. There are two options being con-
sidered by the Director’s Committee members of IEEC, as strategic decisions for the in-
stitute: Acknowledge the importance of the nano-satellite’s market and use the learned
experience from the project to consolidate an engineering unit devoted to small satellite
missions or create a Spin-off and externalize the design and manufacturing of subsys-
tems. The C3 SatP team is working hard to develop a system interesting enough for the
IEEC scientist so the Directors Committee opts for the first option.

8.5 Acknowledgements

We acknowledge the contribution of IEEC and its associated institutes, as well as the
contribution of the Catalan government for the development of the project presented in this
thesis. It has been co-financed in part by IEEC (by providing workforce and installations)
and the grant from the Agaur (Generalitat de Catalunya) call 2016 Producte 0076 (to buy
manufacturing services and components for the prototypes).
Design and integration of a MP-OBC with SDR for nano-satellites 63

References

[1] Cubesat’s market data. https://www.nanosats.eu/#figures.

[2] Planet services. https://www.planet.com/products/monitoring/.
[3] LISA mission. http://sci.esa.int/lisa/.
[4] ARIEL mission. https://arielmission.space/.
[5] Euclid mission. https://www.cosmos.esa.int/web/euclid.
[6] Intitut d’Estudis Espacials de Catalunya (IEEC) webpage. http://www.ieec.cat/
en/content/18/the-ieec.
[7] Institut de Ciències del Cosmos (ICC) webpage. http://icc.ub.edu/about.
[8] CEREs index in Nature. https : / / www . natureindex . com / institution -
outputs/spain/centre- d- estudis- i- recerca- espacials- ceres- uab/
55a4ac98140ba061068b4574.
[9] CTE-CRAE webpage. https://recerca.upc.edu/crae/en/about-crae.
[10] Institut de Ciències de l’Espai (ICE-CSIC) webpage. https://www.ice.csic.es/
en/content/3/history-of-the-institute.
[11] NanoSat Lab webpage. https://nanosatlab.upc.edu/en/presentation.
[12] ISIS webpage. www.isispace.nl.
[13] GOMspace webpage. www.gomspace.com/home.aspx.
[14] Pumpkin Space Systems. www.pumpkinspace.com/.
[15] The CubeSat Shop webpage. www.cubesatshop.com/.
[16] FAPEC compressor webpage. https://www.dapcom.es/fapec/.
[17] Zynq Ultrascale+ models webpage. https : / / www . xilinx . com / products /
silicon-devices/soc/zynq-ultrascale-mpsoc.html.
[18] Zynq Ultrascale+ catalog. https://www.xilinx.com/support/documentation/
selection- guides/zynq- ultrascale- plus- product- selection- guide.
pdf.
[19] SEU Xillinx report. https : / / www . xilinx . com / support / documentation /
white_papers/wp462-ultrascale-SEU.pdf.
[20] & J. Dyer D. Sinclair. Radiation effects and COTS parts in SmallSats. 2013.
[21] V. Kirischian D. M. Hiemstra and J. Brelski. Single Event Upset Characterization of
the Zynq UltraScale+ MPSoC Using Proton Irradiation. 2017, IEEE Radiation Effects
Data Workshop (REDW), New Orleans, LA.
[22] Moses Mwakyanjala, Reza Emami, and Jaap Beek. Software-defined radio transceiver
for QB50 CubeSat telemetry and telecommand. Oct. 2016. DOI: 10.2514/6.2016-
5719.
[23] CubeCat-2 communications issue. https://www.elperiodico.cat/ca/ciencia/
20161002/satellit-cubecat-2-upc-posa-orbita-5438530.
[24] Trenz evaluation kit ZCU102 sotre. https://shop.trenz-electronic.de/en/
28187-Xilinx-Zynq-UltraScale-MPSoC-ZCU102-Evaluation-Kit.
[25] Xillinx Power Estimator. https://www.xilinx.com/products/technology/
power/xpe.html.
[26] Xilinx UG583, Ultrascale Architecture PCB design guide. https://www.xilinx.
com / support / documentation / user _ guides / ug583 - ultrascale - pcb -
design.pdf.
64 Design and integration of a MP-OBC with SDR for nano-satellites

[27] Texas Instruments slva157 application note. http : / / www . ti . com / lit / an /
slva157/slva157.pdf.
[28] Texas Instruments slva477b application note. http : / / www . ti . com / lit / an /
slva477b/slva477b.pdf.
[29] Infineon’s PowIRCenter SW webpage. https://www.infineon.com/cms/en/
product/promopages/power-center-software/.
[30] Cadence PCB tools webpage. https://www.cadence.com/content/cadence-
www/global/en_US/home/tools/pcb-design-and-analysis.html.
[31] Altium Designer webpage. https://www.altium.com/altium-designer/.
[32] Trenz evaluation kit files. https://shop.trenz-electronic.de/en/TE0820-
03-4AE21FA-MPSoC-Module-with-Xilinx-Zynq-UltraScale-ZU4CG-1E-2-
GByte-DDR4-SDRAM-4-x-5-cm.
[33] Mantaro Impedance calculator. https://www.mantaro.com/resources/impedance-
calculator.htm.
[34] Agustı́ Carrillo Caicedo. Disseny i desenvolupament de la estructura mecànica de
l’ordinador a bord del CubeSat C3SatP.
[35] Second Barcelona Techno Week. http://icc.ub.edu/congress/TechnoWeek2017/.
July 2017.
[36] Ignasi Ribas planet hunter. https://www.eso.org/public/news/eso1837/.
[37] Sonar Calling Luyten’s Star. https://www.sonarcalling.com/.
[38] Betevé Sonar Calling documentary. https : / / www . youtube . com / watch ? v =
xn3LMTsQjqY.
[39] Sonar+D Nano-satellites workshop webpage. https : / / sonarplusd . com / en /
programs/barcelona-2018/areas/workshops/how-to-build-a-nanosat.
[40] Sonar+D webpage. https://sonarplusd.com/es.
[41] Thingiverse webpage. https://www.thingiverse.com/.
[42] CubeSats Sonar+D workshop Github repository. https://github.com/nanosatlab/
sonarplusd.
[43] Scientific Sales stratospheric balloons. https://www.scientificsales.com/
Meteorological-Weather-Sounding-Balloon-s/25.htm.
[44] Sonar+D CubeSat workshop coverage. https : / / www . youtube . com / watch ?
time_continue=2&v=HXWHxoEsRJI.
[45] Open Source CubeSat Workshop 2018 webpage. https://oscw.space/oscw18/.
[46] Fossa Systems webpage. http://fossa.systems/.
[47] Call-to-orbit competition. https://open-cosmos.com/call-to-orbit/.
[48] Fly Your Satellite competition. https://www.esa.int/Education/CubeSats_-
_Fly_Your_Satellite.
[49] 4DCube, third winner of the Call-to-orbit competition. https : / / open - cosmos .
com/ieec- 4dcube- third- winner- of- the- open- cosmos- esa- business-
applications-and-esa-space-solutions-call-to-orbit-competition/.
Design and integration of a MP-OBC with SDR for nano-satellites 65

Appendix

A Complete Chronograph

The following pages will present the project evolution with a task chronology in the following
pages.
Design and integration of a MP-OBC with SDR for nano-satellites 69

B OBC and SDR boards mechanical drawings

The following pages will present the physical dimensions of the current versions of the
OBC and the SDR electronic boards. Courtesy of Agustı́ Carrillo.
 6 5 4 3 2 1

,40
15

D 80 D
,01

40,00
12,95 18,95 ,00 53
,0 0
9 2 ,0 0
70
,00
19
0
4 ,5

50,00
89 ,0 0
,0 0 60

13,95
,0 2 9
70 ,7

4,20
85
11 3 ,1
C ,00 4 C
10,15 12,65

8,54
5,50 1,60

3,20
2,54

6,98
40,00

15,24

B B

10,00
18,95 12,95
16,90
4,20

5,39

7,44 13,40

Revisado por Aprobado por Fecha Fecha

A Dise o de
A
Agustin Carrillo Carles Sierra Juan Ramos 05/03/19

C3SatP: OBC (aka Motherboard)

Edici n Hoja
v1.0 2/2

6 5 4 3 2 1
 6 5 4 3 2 1

7,05 54,55 13,05

D D

30,00

30,15
8
8 3,1
8 ,9 0
2,4
35
,51
4,98

,00
1
53
,0 0 70 ,0 0
1 9,3 63
,0 0 80

C C

2,20
3,20

B B

3,99
5,50

Revisado por Aprobado por Fecha Fecha

A Dise o de
A
Agustin Carrillo Carles Sierra Juan Ramos 05/03/19

C3SatP: SDR
Edici n Hoja
v1.0 2/2

6 5 4 3 2 1
72 Design and integration of a MP-OBC with SDR for nano-satellites

C Complete OBDH stack-up design

Figure 33: OBDH stack-up complete definition.

Design and integration of a MP-OBC with SDR for nano-satellites 73

D Open Source CubeSat Workshop poster

The following page will show the whole poser presented in the ESAC conference.
 High-performance on-board computer, data handling
and SDR platform for cubesats
--<< Open Source Cubesat Workshop 24-25 September 2018 European Space Astronomy Center (ESAC/ESA) >>--
Juan Ramos-Castro1,2, Josep Colomé1,3, José María Gómez-Cama1,4, Jordi Portell1,4, Adriano Camps1,2, José Bosch1,4, Manuel Carmona1,4, Contact:
juan.jose.ramos@upc.edu
Albert Casas1,3, Lluís Gesa1,3, Joan Mauricio1,4, 1 Institut d’Estudis Espacials de Catalunya (IEEC), 08034 Barcelona, Spain
2 Grup de Recerca en Ciències i Tecnologies de l’Espai (CTE-CRAE-UPC), 08034 Barcelona, Spain
Juan Francisco Muñoz1,2, David Roma1,3, 3 Institut de Ciències de l’Espai (ICE-CSIC), 08193 Cerdanyola del Vallès, Spain
Carles Sierra1,3, Albert Masip1,4 4 Institut de Ciències del Cosmos (ICCUB), Univ. Barcelona (IEEC-UB), 08028 Barcelona, Spain

Motivation Team and background

Need of a space-qualified platform with: Joint effort of different institutes collaborating inside IEEC: Group of experts from successfully accomplished space missions.
• High-throughput processing capabilities ICE / IEEC-CSIC: CTE / CRAE / UPC: ICCUB / IEEC-UB:
Software for critical applications in space Successfully launched 2 cubesats already •SO/PHI:
• Versatility and reliability
Data Management Unit of LISA PathFinder Working on 3 “3Cat” (“cubecat”) missions: • Image Stabilization system based on
• Easy configuration and use • Processing computer, diagnostic sensors • 3Cat-4: ESA’s “Fly your satellite” program tracking camera.
• Mission critical flight software • 3Cat-5 A/B: FSSCAT Copernicus Masters • Space-qualified hardware and firmware
Solutions available lack of enough power and/or adaptability Currently working on LISA (ESA L3 mission) winner •Gaia:
 custom solutions often needed  overhead to projects • On-board data handling and compression
• On-ground daily data processing
Gaia, the global space
Aim: General-purpose high-performance solution astrometry mission

In-house knowledge and resources  reduce costs,

shorten design & development time, application of lessons
LISA PathFinder
learned from other projects and missions. Technology Package

Overview
Hardware split in 3 boards: Overall operation:
• Motherboard, with On-Board Computer (OBC) • First power-up in orbit  only OBC Acquire telemetry,
• Daughterboard, with On-Board Data Handling (OBDH) comms with ground, monitor all subsystems, activate
• Daughterboard, with Software Defined Radio (SDR) power supply to OBDH and SDR
• OBDH  control payload(s),
EM302 GC600 process data, handle SDR

• SDR  communications and navigation

All internal power supplies:

• Large set of protections (OVP, OCP, thermal…)
• Provide housekeeping data
• Allow changing voltages and sequencing

Optional components and external connectors on the

General Mechanical Structure General Electrical Architecture motherboard depending on mission needs.

On-Board Computer (OBC) On-Board Data Handling (OBDH)

• STM32F446RE µC (ARM® Cortex®-M4 32-bit 180 MHz), DSP and FPU, 512 Kbytes Flash. • Zynq Ultrascale+ XCZU4EG-1L-i (low power, industrial temperature range), High number of programmable
• External Interfaces : I2C, SPI, USART and CAN interface logic resources: 192K logic cells, 18.5Mb memory, 728 DSP slices, 0.72V Core Voltage, Single Event Latch-up
• Inertial Motion Unit (Bosch), 9 deg. freedom (accelerometer, gyroscope, magnetometer) less likely to occur with low core voltage. Enhanced ECC for Single-Event Upset
• Ultra-low power RF transceiver (On Semi), 434 MHz ISM band, simultaneous RX + TX • 2 ARM Cortex-A53 1.5GHz for computing + 2 ARM Cortex-R5 600MHz for real-time. 1GB DDR4 with EDAC
• External Interfaces: I2C, SPI, CAN, RS-485, UART
Software running under FreeRTOS and in charge of spacecraft control and ground Control Software based on Linux using Cortex-A53 processing system with same architecture as
commanding and housekeeping. OBC with Data storage implementing CCSDS File Delivery Protocol and Management of payload(s).
Collect and compress data using FAPEC compressor (time series, lossless/lossy, images, multi/hyperspectral…).

OBC Software Architecture

OBC Electrical Architecture OBDH Electrical Architecture OBDH Software Architecture

Software Architecture Use cases and conclusions

• Extremely modular and reusable with core inherited from the LISA PathFinder • Image processing: on-going study about adding a commercial camera
Payload Software services and methodologies. • EMI scanner to detect spoofing (ESA safety application)
• Following ECSS-E-40 and ECSS-Q-80 standards for software engineering for Space. • GNSS signal processing, either navigation or science
• Designed for multi platform : Hardware (Texas Instrument, STM32, ERC32, Leon, E.g.: ionosphere monitoring, radio occultation, (late) solar flares detection
x86), Operating System (FreeRTOS, RTEMS, Linux ) and multiprotocol (CCDS/PUS, CSP,
CFDP, …) • Any mission requiring fully autonomous on-board massive data processing,
• Based in micro-services approach. allowing to download reduced subset of pre-processed data
E.g.: FFT, light curves, soil/vegetation indicators, etc.

New platform with unprecedented performance capabilities in cubesat-sized missions

Software Defined Radio (SDR) Extremely modular solution:
Based on AD9361 with Wide range supported: 70MHz – 6GHz • Allows adoption by several missions with small changes
• 6 receiver inputs (2 simultaneous)
• SDR + high number of programmable logic resources
• 4 transmitter outputs (2 simultaneous)
• Implement all changes in (isolated) software modules  keep hardware heritage intact
• Fully configurable through SPI interfaces
• 12 LVDS RX/TX data lines, up to 240MHz clock Design ready, implementation well advanced, tests pending
• RX/TX channels optimized for ISM 434 MHz, ISM 2.45 GHz and wide range band
High radiation resiliency Fully operational solution expected for 2019, first flight tests 2020

Acknowledgements
This work has been funded by the the Agència de Gesió d’Ajusts Universitaris i de Recerca of the Generalitat de Catalunya
through project 2016 PROD 00076, including a percentage from European FEDER funds.
Design and integration of a MP-OBC with SDR for nano-satellites 75

E Complete OBDH schematic

The following pages will present the complete schematic of the OBDH electronics.
 1 2 3 4 5 6 7

A
B
C
D

MODEL: PRODUCTE-FPGA BOARD SHEET 1 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: BLOCK DIAGRAM
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

R4_1V2_VCC_PLL R3_2V5_DDR_VPP DDR_VTT_REF

? ? ? ? ? ? ? ?
0.47uF 0.47uF 0.47uF 68pF 68pF 4.7uF 0.1uF 0.1uF
6.3V 10V 10V 16V 16V 6.3V 25V 25V
A

GND GND GND

Layout Note: Use Fly-By Routing and Termination for DDR4 Control Signals
Termination resistors should be placed past the last device as possible

DDR_VTT_REF

? R3_2V5_DDR_VPP R4_1V2_VCC_PLL
240R
1/10W
1%

DDR4 DDR4

VPP2

VDDQ2
VDDQ3
VDDQ4
VDDQ5
VDDQ6

VDD2
VDD3
VDD4
VDD5
VDD6
VDD7
VDD8
ZQ
VREFCA

VPP1

VDDQ1

VDD1
DDR4_ADDR_CMD GND
PS_DDR_A0 A0
PS_DDR_A1 A1 DDR4_DATA_BYTELANE0
PS_DDR_A2 A2
B

PS_DDR_A3 A3
PS_DDR_A4 A4
PS_DDR_A5 A5
PS_DDR_A6 A6 DQ0 PS_DDR_DQ0
PS_DDR_A7 A7 DQ1 PS_DDR_DQ1
DDR4_ADDR_CMD

PS_DDR_A8 A8 DQ2 PS_DDR_DQ2

PS_DDR_A9 A9 DQ3 PS_DDR_DQ3
PS_DDR_A10 A10 DQ4 PS_DDR_DQ4
PS_DDR_A11 A11 DQ5 PS_DDR_DQ5
PS_DDR_A12 A12 DQ6 PS_DDR_DQ6
PS_DDR_A13 A13 DQ7 PS_DDR_DQ7

PS_DDR_BA0 BA0
PS_DDR_BA1 BA1
PS_DDR_BG0 BG0
PS_DDR_BG1 BG1

U1
C0/CKE1
C1/CS1_N
DDR4

C2/ODT1
MT40A1G8WE_075E_IT_B
DDR4_ADDR_CMD
PS_DDR_A14_WE_N WE_N/A14
- Data Bytelane members should be routed on the same layer
C

PS_DDR_A16_RAS_N RAS_N/A16
PS_DDR_A15_CAS_N CAS_N/A15 - Address/command/control/differential clocks should be routed on the same layer, ,
A17 but if space issues arise they can be routed on different layers.
(adjacent layers or layers referencing the same plane layer are preferred)
DDR4_DIFF_CLK
PS_DDR_CK_P - Address/command/control/differential clocks route topology using a daisy chain (fly-by).
CK_T
PS_DDR_CK_N CK_C
PS_DDR_CKE CKE
DQS_T PS_DDR_DQS0_P
DQS_C PS_DDR_DQS0_N
DDR4_ADDR_CMD
PS_DDR_ACT_N ACT_N
PS_DDR_TEN TEN
PS_DDR_ALERT_N ALERT_N
PS_DDR_PAR PAR TDQS_T PS_DDR_DM0
TDQS_C

PS_DDR_RESET_N RESET_N
?
499R PS_DDR_ODT ODT
1/10W
VSSQ1
VSSQ2
VSSQ3
VSSQ4

1%
PS_DDR_CS0_N CS_N
VSS1
VSS2
VSS3
VSS4
VSS5
VSS6
VSS7
VSS8
VSS9

DDR4_CTRL
GND
D

GND

MODEL: PRODUCTE-FPGA BOARD SHEET 2 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: DDR4 SDRAM #1 [7-0]
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

R4_1V2_VCC_PLL R3_2V5_DDR_VPP DDR_VTT_REF DDR_VTT

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
0.47uF 0.47uF 0.47uF 68pF 68pF 4.7uF 0.1uF 0.1uF 4.7uF 4.7uF 4.7uF 0.1uF 0.1uF 0.1uF 0.1uF 0.1uF
A

6.3V 10V 10V 16V 16V 6.3V 25V 25V 6.3V 6.3V 6.3V 25V 25V 25V 25V 25V

GND GND GND GND

DDR_VTT_REF
? R3_2V5_DDR_VPP R4_1V2_VCC_PLL
240R
1/10W
1%

M9

M1
C1
C9

C7

H1

N9
B9

B1

B2
B8

E2
E8

A1

F1

F9
J1

J9
DDR_VTT DDR4

VPP2

VDDQ2
VDDQ3
VDDQ4
VDDQ5
VDDQ6

VDD2
VDD3
VDD4
VDD5
VDD6
VDD7
VDD8
ZQ
VREFCA

VPP1

VDDQ1

VDD1
DDR4_ADDR_CMD GND
40.2R
? PS_DDR_A0_#2 L3 A0
? PS_DDR_A1_#2 L7 A1 DDR4_DATA_BYTELANE1
? PS_DDR_A2_#2 M3 A2
B

? PS_DDR_A3_#2 K7 A3
? PS_DDR_A4_#2 K3 A4
? PS_DDR_A5_#2 L8 A5
? PS_DDR_A6_#2 L2 A6 DQ0 C2 PS_DDR_DQ8
? PS_DDR_A7_#2 M8 A7 DQ1 B7 PS_DDR_DQ9
? PS_DDR_A8_#2 M2 A8 DQ2 D3 PS_DDR_DQ10
? PS_DDR_A9_#2 M7 A9 DQ3 D7 PS_DDR_DQ11
? PS_DDR_A10_#2 J3 A10 DQ4 D2 PS_DDR_DQ12
? PS_DDR_A11_#2 N2 A11 DQ5 D8 PS_DDR_DQ13
? PS_DDR_A12_#2 J7 A12 DQ6 E3 PS_DDR_DQ14
? PS_DDR_A13_#2 N8 A13 DQ7 E7 PS_DDR_DQ15

40.2R
? PS_DDR_BA0_#2 K2 BA0
? PS_DDR_BA1_#2 K8 BA1
? PS_DDR_BG0_#2 J2 BG0
? PS_DDR_BG1_#2 J8 BG1

G2
U2
C0/CKE1
G8 C1/CS1_N
F2 C2/ODT1
MT40A1G8WE_075E_IT_B
40.2R
? PS_DDR_A14_WE_N_#2 H2 WE_N/A14
C

? PS_DDR_A16_RAS_N_#2 H8 RAS_N/A16
R4_1V2_VCC_PLL ? PS_DDR_A15_CAS_N_#2 H7 CAS_N/A15
N7 A17
? DDR4_DIFF_CLK
10nF ? 36R PS_DDR_CK_P_#2 F7
25V CK_T
PS_DDR_CK_N_#2 F8 CK_C
DDR_VTT ? 1/10W PS_DDR_CKE_#2 G3 CKE
1% DQS_T C3 PS_DDR_DQS1_P
DQS_C B3 PS_DDR_DQS1_N
40.2R DDR4_ADDR_CMD
? PS_DDR_ACT_N_#2 H3 ACT_N
PS_DDR_TEN_#2 G9 TEN
PS_DDR_ALERT_N_#2 L9 ALERT_N
40.2R
? PS_DDR_PAR_#2 N3 PAR TDQS_T A7 PS_DDR_DM1
TDQS_C A3
?
499R PS_DDR_RESET_N_#2 L1 RESET_N
1/10W
1%
PS_DDR_ODT_#2 F3 ODT
VSSQ1
VSSQ2
VSSQ3
VSSQ4

PS_DDR_CS0_N_#2 G7 CS_N
VSS1
VSS2
VSS3
VSS4
VSS5
VSS6
VSS7
VSS8
VSS9
GND
D9

C8

H9
A2
A8

A9

E9

K9
D1

N1
E1

G1

K1

DDR_VTT R4_1V2_VCC_PLL
D

4.7K
?
40.2R GND
?
40.2R
?
40.2R
?
4.7K
?
MODEL: PRODUCTE-FPGA BOARD SHEET 3 OF 18
DDR4_CTRL
DRAWN C.SIERRA/A.CASAS TITLE: DDR4 SDRAM #2 [8-15]
VERSION: 1.1
SIZE:A4

GND D.ROMA/J.G.CAMA
CHECKED DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
BANK GND1
?
GND0 GND36
GND1 GND37
BANK GND2
GND2 GND38
GND3 GND39
GND71 GND101
GND4 GND40
GND72 GND102
GND5 GND41
GND73 GND103
GND6 GND42
GND74 GND104
GND7 GND43
GND75 GND105
GND8 GND44
GND76 GND106
GND9 GND45
GND77 GND107
GND10 GND46
GND78 GND108
GND11 GND47
GND79 GND109
B

GND12 GND48
GND80 GND110
GND13 GND49
GND81 GND111
GND14 GND50
GND82 GND112
GND15 GND51
GND83 GND113
GND16 GND52
GND17 GND53
GND84 GND114 ?
GND85 GND115
GND18 GND54
GND86 GND116
BANK RSVDGND
GND19 GND55
GND87 GND117 RSVDGND_0
GND20 GND56
GND88 GND118 RSVDGND_1
GND21 GND57
GND89 GND119 RSVDGND_2
GND22 GND58
GND90 GND120 RSVDGND_3
GND23 GND59
GND91 GND121 RSVDGND_4
GND24 GND60
GND92 GND122
GND25 GND61
GND93 GND123 xczu4cg_sfvc784_1l_i
GND26 GND62
GND94 GND124
GND27 GND63
GND95 GND125
GND28 GND64
GND96 GND126
GND29 GND65
GND97 GND127
GND30 GND66
GND98 GND128
GND31 GND67
GND99 GND129
GND32 GND68
GND100 GND130
GND
GND33 GND69
GND34 GND70
GND35
xczu4cg_sfvc784_1l_i
C

xczu4cg_sfvc784_1l_i
GND GND GND GND
D

MODEL: PRODUCTE-FPGA BOARD SHEET 4 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ GND
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
BANK 505
PS_MGTRRXN0_505
PS_MGTRRXN1_505
PS_MGTRRXN2_505
PS_MGTRRXN3_505
PS_MGTRRXP0_505
PS_MGTRRXP1_505
B

PS_MGTRRXP2_505
PS_MGTRRXP3_505
PS_MGTRTXN0_505
PS_MGTRTXN1_505 (UG583 (1.13, 2018), p.185)
PS_MGTRTXN2_505
PS_MGTRTXN3_505
PS_MGTRTXP0_505
PS_MGTRTXP1_505
PS_MGTRTXP2_505
PS_MGTRTXP3_505
PS_MGTREFCLK0N_505
PS_MGTREFCLK0P_505
PS_MGTREFCLK1N_505
PS_MGTREFCLK1P_505
PS_MGTREFCLK2N_505
PS_MGTREFCLK2P_505
PS_MGTREFCLK3N_505
PS_MGTREFCLK3P_505
PS_MGTRREF_505

xczu4cg_sfvc784_1l_i

GND
C
D

MODEL: PRODUCTE-FPGA BOARD SHEET 5 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ BANKS 505 GTR
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

? R5_1V8_VCCO_PSIO
?
CLK VDD
GND OE_/ST 120 Ohm @ 100 MHz
R5_1V8_VCCO_PSIO ? 3A Notes:
? 0.47uF
SIT8008BI-71-18S-33.33E 25V
@PS_REF_CLK
? ? 33R - R as close as possible to the pin
4.7K 1/10W
-Terminations for impedance matching JTAG_TCK i PS_REF_CLK
System Reset Debug
BANK 503 1/16W
1%
1%
GND GND - NO Glitches at first cycle
A

PS_SRST_B PS_SRST_B
PS_POR_B PS_POR_B
IN
PS_ERROR_STATUS B503_PS_ERROR_STATUS
OUT
PS_ERROR_OUT B503_PS_ERROR_OUT
OUT
R5_1V8_VCCO_PSIO R5_1V8_VCCO_PSIO
PS_REF_CLK PS_REF_CLK

PS_JTAG_TCK JTAG_TCK Boot Mode Selected: SD0 (2.0)

IN ? ? ? ? ? ? ?
PS_JTAG_TMS JTAG_TMS Mode Pins [3:0] 0011
IN 4.7K 4.7K 4.7K 4.7K 4.7K 4.7K 4.7K
PS_JTAG_TDI JTAG_TDI
IN 1/16W 1/16W 1/16W 1/16W 1/16W 1/16W 1/16W
PS_JTAG_TDO JTAG_TDO
OUT 1% 1% 1% 1% 1% 1% 1%
0R ? 1/10W
PS_INIT_B B503_PS_INIT_B
IO ?
PS_PROG_B PS_PROG_B 0R 1/10W
PS_DONE PS_DONE
OUT 0R ? 1/10W

PS_PADI PS_PADI 0R ? 1/10W

IN
PS_PADO PS_PADO
OUT
PS_MODE0 PS_MODE0 ? ? ? ?
PS_MODE1 PS_MODE1 499R 499R 499R 499R
PS_MODE2 PS_MODE2 1/10W 1/10W 1/10W 1/10W
PS_MODE3 1% 1% 1% 1%
PS_MODE3
R5_1V8_VCCO_PSIO
B

VCCO_PSIO3_503_0
?
VCCO_PSIO3_503_1
20R GND
1/16W
1%

AC termination for impedance matching

?
xczu4cg_sfvc784_1l_i 33pF
50V

GND

VDD_MB_5V VDD_MB_5V
Power-On Reset
4.7K 4.7K
? 1/16W ? 1/16W
VDD_MB_5V
1% 1% R5_1V8_VCCO_PSIO
C

R5_1V8_VCCO_PSIO
? DONE=0, LED OFF ? INIT_B=0, LED OFF ? ?
0.1uF
DONE=1, LED ON INIT_B=1, LED ON 1.5K 25V
1/10W ?
1%
? 4.7K
1.565V 1/16W
D D SENSE VDD
1%
? ? ? NC GND
10K GND /RESET PS_POR_B
1/10W
? ? 1% ?
PS_DONE G B503_PS_INIT_B G TPS3803_01_Q1 0.1uF
25V
1K 1K
1/16W 1% 1/16W 1%
S S

GND GND GND

GND GND

Real Time External Clock

Power Supply Recommendations
The TPS380x-Q1 devices are designed to operate from an input supply from 1.3 V to 6 V (Vdd max=7V).
? ? 32.768KHz
Threshold Voltage Sense: 1.226V
D

X1
4.7M TI recommends to place a 0.1-µF capacitor near the VDD pin
1/10W
PS_PADI 5% X2

PS_PADO 20ppm

? ?
22pF 22pF
50V 50V

MODEL: PRODUCTE-FPGA BOARD SHEET 6 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: BANK 503: PS_CONFIG
VERSION: 1.1
SIZE:A4

GND D.ROMA/J.G.CAMA
CHECKED DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
BANK 504
DDR4 DDR4
DDR4_DATA_BYTELANE0
DDR4_ADDR_CMD
PS_DDR_A0 PS_DDR_A0 PS_DDR_DQ0 PS_DDR_DQ0
PS_DDR_A1 PS_DDR_A1 PS_DDR_DQ1 PS_DDR_DQ1
PS_DDR_A2 PS_DDR_A2 PS_DDR_DQ2 PS_DDR_DQ2
PS_DDR_A3 PS_DDR_A3 PS_DDR_DQ3 PS_DDR_DQ3
PS_DDR_A4 PS_DDR_A4 PS_DDR_DQ4 PS_DDR_DQ4
A

PS_DDR_A5 PS_DDR_A5 PS_DDR_DQ5 PS_DDR_DQ5

PS_DDR_A6 PS_DDR_A6 PS_DDR_DQ6 PS_DDR_DQ6
PS_DDR_A7 PS_DDR_A7 PS_DDR_DQ7 PS_DDR_DQ7 DDR4_DATA_BYTELANE1
PS_DDR_A8 PS_DDR_A8 PS_DDR_DQ8 PS_DDR_DQ8
PS_DDR_A9 PS_DDR_A9 PS_DDR_DQ9 PS_DDR_DQ9
PS_DDR_A10 PS_DDR_A10 PS_DDR_DQ10 PS_DDR_DQ10
PS_DDR_A11 PS_DDR_A11 PS_DDR_DQ11 PS_DDR_DQ11
PS_DDR_A12 PS_DDR_A12 PS_DDR_DQ12 PS_DDR_DQ12
PS_DDR_A13 PS_DDR_A13 PS_DDR_DQ13 PS_DDR_DQ13
PS_DDR_A14_WE_N PS_DDR_A14 PS_DDR_DQ14 PS_DDR_DQ14
PS_DDR_A15_CAS_N PS_DDR_A15 PS_DDR_DQ15 PS_DDR_DQ15
PS_DDR_A16_RAS_N PS_DDR_A16 PS_DDR_DQ16
PS_DDR_A17 PS_DDR_DQ17
PS_DDR_BA0 PS_DDR_BA0 PS_DDR_DQ18
PS_DDR_BA1 PS_DDR_BA1 PS_DDR_DQ19
PS_DDR_ACT_N PS_DDR_ACT_N PS_DDR_DQ20
PS_DDR_PAR PS_DDR_PARITY PS_DDR_DQ21
PS_DDR_ALERT_N PS_DDR_ALERT_N PS_DDR_DQ22
PS_DDR_RESET_N PS_DDR_RAM_RST_N PS_DDR_DQ23
PS_DDR_BG0 PS_DDR_BG0 PS_DDR_DQ24
DDR4_CTRL
PS_DDR_BG1 PS_DDR_BG1 PS_DDR_DQ25
PS_DDR_CS0_N PS_DDR_CS_N0 PS_DDR_DQ26
PS_DDR_CS_N1 PS_DDR_DQ27
PS_DDR_CK_P PS_DDR_CK0 PS_DDR_DQ28
DDR4_ADDR_CMD PS_DDR_CK_N PS_DDR_CK_N0 PS_DDR_DQ29
B

PS_DDR_CK1 PS_DDR_DQ30
PS_DDR_CK_N1 PS_DDR_DQ31
PS_DDR_CKE PS_DDR_CKE0 PS_DDR_DQ32
DDR4_CTRL PS_DDR_CKE1 PS_DDR_DQ33
PS_DDR_ODT PS_DDR_ODT0 PS_DDR_DQ34
PS_DDR_ODT1 PS_DDR_DQ35
PS_DDR_DQS0_P PS_DDR_DQS_P0 PS_DDR_DQ36
PS_DDR_DQS0_N PS_DDR_DQS_N0 PS_DDR_DQ37
DDR4_DIFF_CLK PS_DDR_DQS1_P PS_DDR_DQS_P1 PS_DDR_DQ38
PS_DDR_DQS1_N PS_DDR_DQS_N1 PS_DDR_DQ39
PS_DDR_DQS_P2 PS_DDR_DQ40
PS_DDR_DQS_N2 PS_DDR_DQ41
PS_DDR_DQS_P3 PS_DDR_DQ42
DDR4_DATA_BYTELANE0 PS_DDR_DQS_N3 PS_DDR_DQ43
PS_DDR_DQS_P4 PS_DDR_DQ44
PS_DDR_DQS_N4 PS_DDR_DQ45
PS_DDR_DQS_P5 PS_DDR_DQ46
PS_DDR_DQS_N5 PS_DDR_DQ47
DDR4_DATA_BYTELANE1 PS_DDR_DQS_P6 PS_DDR_DQ48
PS_DDR_DQS_N6 PS_DDR_DQ49
PS_DDR_DQS_P7 PS_DDR_DQ50
PS_DDR_DQS_N7 PS_DDR_DQ51
PS_DDR_DQS_P8 PS_DDR_DQ52
PS_DDR_DQS_N8 PS_DDR_DQ53
PS_DDR_DM0 PS_DDR_DM0 PS_DDR_DQ54
C

PS_DDR_DM1 PS_DDR_DM1 PS_DDR_DQ55

PS_DDR_DM2 PS_DDR_DQ56
PS_DDR_DM3 PS_DDR_DQ57
PS_DDR_DM4 PS_DDR_DQ58
PS_DDR_DM5 PS_DDR_DQ59
PS_DDR_DM6 PS_DDR_DQ60
PS_DDR_DM7 PS_DDR_DQ61
PS_DDR_DM8 PS_DDR_DQ62
PS_DDR_DQ63
PS_DDR_DQ64
PS_DDR_DQ65
PS_DDR_DQ66
PS_DDR_DQ67
PS_DDR_DQ68
PS_DDR_DQ69
PS_DDR_DQ70
PS_DDR_DQ71
R4_1V2_VCC_PLL

VCCO_PSDDR_504_0 PS_DDR_ZQ
VCCO_PSDDR_504_1
VCCO_PSDDR_504_2 ?
VCCO_PSDDR_504_3 240R LAYOUT NOTE: Place ZQ resistor close to the BANK 504.
1/10W
VCCO_PSDDR_504_4 1%
VCCO_PSDDR_504_5
D

VCCO_PSDDR_504_6

xczu4cg_sfvc784_1l_i GND

MODEL: PRODUCTE-FPGA BOARD SHEET 7 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: PS DDR4 MEMORY
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

R3_1V8_VCC_PSAUX

?
? 1K
BANK 0 1/16W
1%
The FPGA PUDC_B pin is tied to GND
PUDC_B to enable internal pull-ups or it can be
POR_OVERRIDE tied to VCCO_0 to 3-state the SelectIO pins
DXP SYSMON_DX_P (I/O Banks, type HP or HD) after power-up
?
B

DXN SYSMON_DX_N and during configuration.

DNP
VCCADC 1V8_VCC_PSADC GND
GNDADC
VREFP
VREFN
VP ? GND
VN 0.1uF
25V

xczu4cg_sfvc784_1l_i Connect VREFP and VREFN to GND

when using internal reference.
GND
C
D

MODEL: PRODUCTE-FPGA BOARD SHEET 8 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ BANK 0 SYSMON
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
BANK 224

MGTHTXP0_224 NC
MGTHTXN0_224 NC
MGTHRXP0_224
MGTHRXN0_224
MGTHTXP1_224 NC
MGTHTXN1_224 NC
MGTHRXP1_224
MGTHRXN1_224
B

MGTHTXP2_224 NC
MGTHTXN2_224 NC
MGTHRXP2_224
MGTHRXN2_224
MGTHTXP3_224 NC
NC (UG576, p.331-333)
MGTHTXN3_224
MGTHRXP3_224
MGTHRXN3_224
MGTREFCLK0P_224
MGTREFCLK0N_224
MGTREFCLK1P_224
MGTREFCLK1N_224
MGTRREF_R
MGTAVTTRCAL_R

xczu4cg_sfvc784_1l_i GND
C
D

MODEL: PRODUCTE-FPGA BOARD SHEET 9 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ BANKS 224 (GTH QUAD)
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
?
BANK 45
BANK 43
IO_L12N_AD8N_45
IO_L12N_AD0N_43 ? 30R B43_AB9_SDR_SPI_CLK
IO_L12P_AD8P_45
IO_L12P_AD0P_43 ? 30R B43_AB10_SDR_MISO
IO_L11N_AD9N_45
IO_L11N_AD1N_43 B43_AA8_SDR_EN
B43_Y9_SDR_EN_AGC IO_L11P_AD9P_45
IO_L11P_AD1P_43
B43_Y10_SDR_CNTRLI_1 IO_L10N_AD10N_45
IO_L10N_AD2N_43
A

B43_W10_SDR_CNTRLI_2 IO_L10P_AD10P_45
IO_L10P_AD2P_43
B43_AA10_SDR_RST_N IO_L9N_AD11N_45
IO_L9N_AD3N_43
IO_L9P_AD11P_45
IO_L9P_AD3P_43 ? 30R B43_AA11_SDR_MOSI
IO_L8N_HDGC_45
IO_L8N_HDGC_AD4N_43 B43_AC11_SDR_CNTRLO_3
IO_L8P_HDGC_45
IO_L8P_HDGC_AD4P_43 ? 30R B43_AB11_SDR_SPI_CS_N
IO_L7N_HDGC_45
IO_L7N_HDGC_AD5N_43 B43_AD10_SDR_CNTRLO_0
B43_AD11_SDR_TX_RX IO_L7P_HDGC_45
IO_L7P_HDGC_AD5P_43
B43_AD12_SDR_CNTRLO_7 IO_L6N_HDGC_45
IO_L6N_HDGC_AD6N_43
B43_AC12_SDR_CNTRLO_1 IO_L6P_HDGC_45
IO_L6P_HDGC_AD6P_43
B43_AF12_SDR_CNTRLI_3 IO_L5N_HDGC_45
IO_L5N_HDGC_AD7N_43
B43_AE12_SDR_CNTRLO_5 IO_L5P_HDGC_45
IO_L5P_HDGC_AD7P_43
B43_AF10_SDR_CNTRLO_6 IO_L4N_AD12N_45
IO_L4N_AD8N_43
B43_AE10_SDR_CNTRLI_0 IO_L4P_AD12P_45
IO_L4P_AD8P_43
B43_AH11_USB0_PWR_SW IO_L3N_AD13N_45
IO_L3N_AD9N_43
IO_L3P_AD13P_45
IO_L3P_AD9P_43
B43_AG11_SDR_CNTRLO_2 IO_L2N_AD14N_45
IO_L2N_AD10N_43
B43_AF11_SDR_CNTRLO_4 IO_L2P_AD14P_45
IO_L2P_AD10P_43
IO_L1N_AD15N_45
IO_L1N_AD11N_43
IO_L1P_AD15P_45
R5_1V8_VCCO_PSIO IO_L1P_AD11P_43

VCCO_45_0
VCCO_43_0
VCCO_45_1
VCCO_43_1

xczu4cg_sfvc784_1l_i xczu4cg_sfvc784_1l_i
B

The HD (high density) I/O banks are designed to support low-speed interfaces. (UG571)
We will use the HP I/O banks instead of HD I/O Banks, because the FPGA
has far more I/O pins than the design requires and HP have better requirements.
The HP I/O banks are designed to meet the performance requirements of high-speed
GND GND memory and other chip-to-chip interfaces with voltages up to 1.8V.

(BANK 0 configures them as 3-state I/O after power-up and during configuration.)

? ?
BANK 44 BANK 46 Leaving the VCCO pins of unused I/O banks floating reduces the level of ESD protection on
these pins and the I/O pins in the bank. For maximum ESD protection in an unused bank, all
VCCO and I/O pins in that bank should be connected together to the same potential,
whether that be ground, a valid VCCO voltage, or a floating plane. (ug583, p.220)
IO_L12N_AD0N_46
IO_L12N_AD8N_44
IO_L12P_AD0P_46
IO_L12P_AD8P_44
IO_L11N_AD1N_46
IO_L11N_AD9N_44
IO_L11P_AD1P_46
IO_L11P_AD9P_44
IO_L10N_AD2N_46
IO_L10N_AD10N_44
IO_L10P_AD2P_46
IO_L10P_AD10P_44
IO_L9N_AD3N_46
IO_L9N_AD11N_44
IO_L9P_AD3P_46
IO_L9P_AD11P_44
IO_L8N_HDGC_AD4N_46
IO_L8N_HDGC_44
IO_L8P_HDGC_AD4P_46
C

IO_L8P_HDGC_44
IO_L7N_HDGC_AD5N_46
IO_L7N_HDGC_44
IO_L7P_HDGC_AD5P_46
IO_L7P_HDGC_44
IO_L6N_HDGC_AD6N_46
IO_L6N_HDGC_44
IO_L6P_HDGC_AD6P_46
IO_L6P_HDGC_44
IO_L5N_HDGC_AD7N_46
IO_L5N_HDGC_44
IO_L5P_HDGC_AD7P_46
IO_L5P_HDGC_44
IO_L4N_AD8N_46
IO_L4N_AD12N_44
IO_L4P_AD8P_46
IO_L4P_AD12P_44
IO_L3N_AD9N_46
IO_L3N_AD13N_44
IO_L3P_AD9P_46
IO_L3P_AD13P_44
IO_L2N_AD10N_46
IO_L2N_AD14N_44
IO_L2P_AD10P_46
IO_L2P_AD14P_44
IO_L1N_AD11N_46
IO_L1N_AD15N_44
IO_L1P_AD11P_46
IO_L1P_AD15P_44

VCCO_44_0
VCCO_46_0
VCCO_44_1
VCCO_46_1

xczu4cg_sfvc784_1l_i
xczu4cg_sfvc784_1l_i
D

GND GND

MODEL: PRODUCTE-FPGA BOARD SHEET 10 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ HD BANKS
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

? ? ?
BANK 66 BANK65 BANK 64
IO_L24N_T3U_N11_64 B64_AG1_L24_N
IO_L24P_T3U_N10_64 B64_AF1_L24_P
A

IO_L24N_T3U_N11_66 B66_B9_RS485_RX_/RE IO_L24N_T3U_N11_PERSTN0_65 IO_L23N_T3U_N9_64 B64_AH1_L23_N

IO_L24P_T3U_N10_66 ? 30R B66_C9_USART_OBDH_CTS IO_L24P_T3U_N10_PERSTN1_I2C_SDA_65 B65_H9_HK_I2C_SDA IO_L23P_T3U_N8_64 B64_AH2_L23_P
IO_L23N_T3U_N9_66 B66_A8_RS485_TX_DE IO_L23N_T3U_N9_65 IO_L22N_T3U_N7_DBC_AD0N_64 B64_AF2_L22_N
IO_L23P_T3U_N8_66 B66_A9_RS485_RX_RO IO_L23P_T3U_N8_I2C_SCLK_65 B65_K9_HK_I2C_SCL IO_L22P_T3U_N6_DBC_AD0P_64 B64_AE2_L22_P
IO_L22N_T3U_N7_DBC_AD0N_66 B66_B8_RS485_TX_DI IO_L22N_T3U_N7_DBC_AD0N_65 IO_L21N_T3L_N5_AD8N_64 B64_AF3_L21_N
IO_L22P_T3U_N6_DBC_AD0P_66 B66_C8_USART_OBDH_TX IO_L22P_T3U_N6_DBC_AD0P_65 IO_L21P_T3L_N4_AD8P_64 B64_AE3_L21_P
IO_L21N_T3L_N5_AD8N_66 B66_A6_USB_RST IO_L21N_T3L_N5_AD8N_65 IO_L20N_T3L_N3_AD1N_64 B64_AH3_L20_N
IO_L21P_T3L_N4_AD8P_66 B66_A7_RS485_RX_/SLO IO_L21P_T3L_N4_AD8P_65 IO_L20P_T3L_N2_AD1P_64 B64_AG3_L20_P
IO_L20N_T3L_N3_AD1N_66 IO_L20N_T3L_N3_AD1N_65 IO_L19N_T3L_N1_DBC_AD9N_64 B64_AH4_L19_N
IO_L20P_T3L_N2_AD1P_66 IO_L20P_T3L_N2_AD1P_65 IO_L19P_T3L_N0_DBC_AD9P_64 B64_AG4_L19_P
IO_L19N_T3L_N1_DBC_AD9N_66 IO_L19N_T3L_N1_DBC_AD9N_65 IO_T3U_N12_64
IO_L19P_T3L_N0_DBC_AD9P_66 IO_L19P_T3L_N0_DBC_AD9P_65 IO_T2U_N12_64
IO_T3U_N12_66 IO_T3U_N12_65 IO_L18N_T2U_N11_AD2N_64 B64_AC1_L18_N
IO_T2U_N12_66 IO_T2U_N12_65 IO_L18P_T2U_N10_AD2P_64 B64_AB1_L18_P
IO_L18N_T2U_N11_AD2N_66 B66_D9_USART_OBDH_CK IO_L18N_T2U_N11_AD2N_65 IO_L17N_T2U_N9_AD10N_64 B64_AC2_L17_N
IO_L18P_T2U_N10_AD2P_66 B66_E9_USART_OBDH_RTS IO_L18P_T2U_N10_AD2P_65 IO_L17P_T2U_N8_AD10P_64 B64_AB2_L17_P
IO_L17N_T2U_N9_AD10N_66 ? 30R B66_E8_USART_OBDH_RX IO_L17N_T2U_N9_AD10N_65 IO_L16N_T2U_N7_QBC_AD3N_64 B64_AD1_L16_N
IO_L17P_T2U_N8_AD10P_66 IO_L17P_T2U_N8_AD10P_65 IO_L16P_T2U_N6_QBC_AD3P_64 B64_AD2_L16_P
IO_L16N_T2U_N7_QBC_AD3N_66 B66_F7_SDR_RX_D4_N IO_L16N_T2U_N7_QBC_AD3N_65 IO_L15N_T2L_N5_AD11N_64
IO_L16P_T2U_N6_QBC_AD3P_66 B66_G8_SDR_RX_D4_P IO_L16P_T2U_N6_QBC_AD3P_65 IO_L15P_T2L_N4_AD11P_64
IO_L15N_T2L_N5_AD11N_66 B66_F6_SDR_RX_D5_N IO_L15N_T2L_N5_AD11N_65 IO_L14N_T2L_N3_GC_64
IO_L15P_T2L_N4_AD11P_66 B66_G6_SDR_RX_D5_P IO_L15P_T2L_N4_AD11P_65 IO_L14P_T2L_N2_GC_64
IO_L14N_T2L_N3_GC_66 B66_D5_SDR_RX_D3_N IO_L14N_T2L_N3_GC_65 IO_L13N_T2L_N1_GC_QBC_64
IO_L14P_T2L_N2_GC_66 B66_E5_SDR_RX_D3_P IO_L14P_T2L_N2_GC_65 IO_L13P_T2L_N0_GC_QBC_64
IO_L13N_T2L_N1_GC_QBC_66 B66_D6_SDR_DATA_CLK_N IO_L13N_T2L_N1_GC_QBC_65 IO_L12N_T1U_N11_GC_64 B64_AE5_L12_N
B

IO_L13P_T2L_N0_GC_QBC_66 B66_D7_SDR_DATA_CLK_P IO_L13P_T2L_N0_GC_QBC_65 IO_L12P_T1U_N10_GC_64 B64_AF5_L12_P

IO_L12N_T1U_N11_GC_66 B66_C2_SDR_FB_CLK_N IO_L12N_T1U_N11_GC_65 IO_L11N_T1U_N9_GC_64 B64_AF6_L11_N
IO_L12P_T1U_N10_GC_66 B66_C3_SDR_FB_CLK_P IO_L12P_T1U_N10_GC_65 IO_L11P_T1U_N8_GC_64 B64_AF7_L11_P
IO_L11N_T1U_N9_GC_66 B66_C4_SDR_TX_D4_N IO_L11N_T1U_N9_GC_65 IO_L10N_T1U_N7_QBC_AD4N_64 B64_AG5_L10_N
IO_L11P_T1U_N8_GC_66 B66_D4_SDR_TX_D4_P IO_L11P_T1U_N8_GC_65 IO_L10P_T1U_N6_QBC_AD4P_64 B64_AG6_L10_P
IO_L10N_T1U_N7_QBC_AD4N_66 B66_F1_SDR_TX_D0_N IO_L10N_T1U_N7_QBC_AD4N_65 IO_L9N_T1L_N5_AD12N_64 B64_AH7_L9_N
IO_L10P_T1U_N6_QBC_AD4P_66 B66_G1_SDR_TX_D0_P IO_L10P_T1U_N6_QBC_AD4P_65 IO_L9P_T1L_N4_AD12P_64 B64_AH8_L9_P
IO_L9N_T1L_N5_AD12N_66 B66_A3_SDR_TX_D2_N IO_L9N_T1L_N5_AD12N_65 IO_L8N_T1L_N3_AD5N_64 B64_AG8_L8_N
IO_L9P_T1L_N4_AD12P_66 B66_B3_SDR_TX_D2_P IO_L9P_T1L_N4_AD12P_65 IO_L8P_T1L_N2_AD5P_64 B64_AF8_L8_P
IO_L8N_T1L_N3_AD5N_66 B66_A1_SDR_RX_D2_N IO_L8N_T1L_N3_AD5N_65 IO_L7N_T1L_N1_QBC_AD13N_64 B64_AH9_L7_N
IO_L8P_T1L_N2_AD5P_66 B66_A2_SDR_RX_D2_P IO_L8P_T1L_N2_AD5P_65 IO_L7P_T1L_N0_QBC_AD13P_64 B64_AG9_L7_P
IO_L7N_T1L_N1_QBC_AD13N_66 B66_B1_SDR_RX_D1_N IO_L7N_T1L_N1_QBC_AD13N_65 IO_T1U_N12_64
IO_L7P_T1L_N0_QBC_AD13P_66 B66_C1_SDR_RX_D1_P IO_L7P_T1L_N0_QBC_AD13P_65 IO_T0U_N12_VRP_64
IO_T1U_N12_66 IO_T1U_N12_65 IO_L6N_T0U_N11_AD6N_64
IO_T0U_N12_VRP_66 IO_T0U_N12_VRP_65 IO_L6P_T0U_N10_AD6P_64
IO_L6N_T0U_N11_AD6N_66 B66_F5_SDR_TX_D5_N IO_L6N_T0U_N11_AD6N_65 IO_L5N_T0U_N9_AD14N_64
IO_L6P_T0U_N10_AD6P_66 B66_G5_SDR_TX_D5_P IO_L6P_T0U_N10_AD6P_65 IO_L5P_T0U_N8_AD14P_64
IO_L5N_T0U_N9_AD14N_66 B66_E3_SDR_RX_FRAME_N IO_L5N_T0U_N9_AD14N_65 IO_L4N_T0U_N7_DBC_AD7N_64
IO_L5P_T0U_N8_AD14P_66 B66_E4_SDR_RX_FRAME_P IO_L5P_T0U_N8_AD14P_65 IO_L4P_T0U_N6_DBC_AD7P_64
IO_L4N_T0U_N7_DBC_AD7N_66 B66_F3_SDR_TX_D3_N IO_L4N_T0U_N7_DBC_AD7N_65 IO_L3N_T0L_N5_AD15N_64
IO_L4P_T0U_N6_DBC_AD7P_66 B66_G3_SDR_TX_D3_P IO_L4P_T0U_N6_DBC_AD7P_SMBALERT_65 B65_R8_HK_I2C_ALERT_N IO_L3P_T0L_N4_AD15P_64
IO_L3N_T0L_N5_AD15N_66 B66_E2_SDR_TX_FRAME_N IO_L3N_T0L_N5_AD15N_65 IO_L2N_T0L_N3_64
IO_L3P_T0L_N4_AD15P_66 B66_F2_SDR_TX_FRAME_P IO_L3P_T0L_N4_AD15P_65 IO_L2P_T0L_N2_64
IO_L2N_T0L_N3_66 B66_D1_SDR_TX_D1_N IO_L2N_T0L_N3_65 IO_L1N_T0L_N1_DBC_64
IO_L2P_T0L_N2_66 B66_E1_SDR_TX_D1_P IO_L2P_T0L_N2_65 IO_L1P_T0L_N0_DBC_64
C

IO_L1N_T0L_N1_DBC_66 B66_F1_SDR_RX_D0_N IO_L1N_T0L_N1_DBC_65

IO_L1P_T0L_N0_DBC_66 B66_G1_SDR_RX_D0_P IO_L1P_T0L_N0_DBC_65
R5_1V8_VCCO_PSIO
R5_1V8_VCCO_PSIO ?
R5_1V8_VCCO_PSIO VCCO_64_0 VREF_64
? VCCO_64_1
? 1K
VCCO_66_0 VREF_66 VCCO_64_2 1/16W
VCCO_65_0 VREF_65
VCCO_66_1 1%
1K VCCO_65_1
VCCO_66_2 1/16W 1K
VCCO_65_2
1% 1/16W
1%
GND GND xczu4cg_sfvc784_1l_i GND
xczu4cg_sfvc784_1l_i
xczu4cg_sfvc784_1l_i

Leaving the VCCO pins of unused I/O banks floating reduces the level of ESD protection on
these pins and the I/O pins in the bank. For maximum ESD protection in an unused bank, all
VCCO and I/O pins in that bank should be connected together to the same potential,
whether that be ground, a valid VCCO voltage, or a floating plane. (ug583, p.220)
D

In banks where the input I/O standard has an input reference voltage requirement and uses an
internally generated VREF (INTERNAL_VREF or VREF scan), connect
the dedicated VREF pin to GND with a 500O or 1KO resistor, or leave it floating.
(UG571, p.21)

MODEL: PRODUCTE-FPGA BOARD SHEET 11 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ HP BANKS
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

?
BANK PS_POWER
R4_1V2_VCC_PLL
?
VCC_PSPLL_0
R2_0V85_VCC_PSINTLP BANK MGTAVCC_R
VCC_PSPLL_1
VCC_PSPLL_2 MGTAVCC_R_0
A

VCC_PSINTLP_0 MGTAVCC_R_1
VCC_PSINTLP_1
VCC_PSINTLP_2
VCC_PSINTLP_3
VCC_PSINTLP_4 xczu4cg_sfvc784_1l_i GND
VCC_PSINTLP_5
VCC_PSINTFP_DDR_0
VCC_PSINTFP_DDR_1
VCC_PSINTFP_DDR_2
VCC_PSINTFP_0
VCC_PSINTFP_1
VCC_PSINTFP_2
VCC_PSINTFP_3
VCC_PSINTFP_4
?
VCC_PSINTFP_5 1V8_VCC_PSDDR_PLL
VCC_PSINTFP_6
BANK MGTAVTT_R
VCC_PSDDR_PLL_0
VCC_PSDDR_PLL_1
R5_1V8_VCC_PSAUX
MGTAVTT_R_0
VCC_PSBATT
MGTAVTT_R_1
VCC_PSAUX_0
VCC_PSAUX_1 1V8_VCC_PSADC
VCC_PSAUX_2
VCC_PSAUX_3
VCC_PSADC xczu4cg_sfvc784_1l_i GND
GND_PSADC
B

600 Ohm @ 100 MHz

500mA

xczu4cg_sfvc784_1l_i AGND GND

?
BANK MGTVCCAUX_R
? R1_0V72_VCCINT
BANK VCCINT ? MGTVCCAUX_R_0
MGTVCCAUX_R_1
BANK VCCAUX R3_1V8_VCC_PSAUX
VCCINT_0
VCCINT_1 VCCAUX_0
VCCINT_2 VCCAUX_1
VCCINT_3
xczu4cg_sfvc784_1l_i GND
VCCINT_4
VCCINT_5
VCCINT_6
xczu4cg_sfvc784_1l_i
VCCINT_7
VCCINT_8
VCCINT_9
VCCINT_10 ?
C

VCCINT_11
VCCINT_12 BANK VCCAUX_IO R3_1V8_VCC_PSAUX
VCCINT_13 ? ?
VCCINT_14
VCCINT_15 VCCAUX_IO_0 BANK PS_MGTRAVTT BANK PS_MGTRAVCC
VCCINT_16 VCCAUX_IO_1
VCCINT_17 VCCAUX_IO_2
PS_MGTRAVTT_0
PS_MGTRAVTT_1 PS_MGTRAVCC_0
PS_MGTRAVTT_2 PS_MGTRAVCC_1
xczu4cg_sfvc784_1l_i xczu4cg_sfvc784_1l_i PS_MGTRAVTT_3

xczu4cg_sfvc784_1l_i
? xczu4cg_sfvc784_1l_i GND
? GND
BANK VCCINT_IO R2_0V85_VCC_PSINTLP BANK VCCBRAM R2_0V85_VCC_PSINTLP

If an entire power supply group (PSG)

VCCINT_IO_0 VCCBRAM_0
is not used by any GTH Quads, the
VCCINT_IO_1 VCCBRAM_1
associated pins can be left unconnected
VCCINT_IO_2 VCCBRAM_2
or should tied to GND: MGTAVTT, MGTRREF...
VCCINT_IO_3 VCCBRAM_3
(UG576)
D

xczu4cg_sfvc784_1l_i xczu4cg_sfvc784_1l_i

MODEL: PRODUCTE-FPGA BOARD SHEET 12 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ POWER 1
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

Internal Satellite Communication Buses:

? UART / SPI / I2C(PMBus) / CAN ?
BANK 500 BANK 502
PS_MIO0 MIO0_CAN0_STBY_OBDH
PS_MIO52 MIO52_USB0_CLK_OBDH
PS_MIO1 MIO53_USB0_DIR_OBDH
MIO2_CAN0_RX_OBDH PS_MIO53
PS_MIO2 USB 2.0 to Umbilicals
PS_MIO3 MIO3_CAN0_TX_OBDH PS_MIO54 ? 30R MIO54_USB0_D2_OBDH
and Payload (if required)
A

PS_MIO55 MIO55_USB0_NXT_OBDH
PS_MIO4
PS_MIO5 MIO5_OBDH_GPIO_0 PS_MIO56 ? 30R MIO56_USB0_D0_OBDH

PS_MIO6 MIO6_OBDH_GPIO_1 PS_MIO57 ? 30R MIO57_USB0_D1_OBDH

PS_MIO7 MIO7_OBDH_GPIO_2 PS_MIO58 ? 30R MIO58_USB0_STP_OBDH

PS_MIO8 MIO8_OBDH_GPIO_3 PS_MIO59 ? 30R MIO59_USB0_D3_OBDH

PS_MIO9 MIO9_OBDH_GPIO_4 PS_MIO60 ? 30R MIO60_USB0_D4_OBDH

PS_MIO10
PS_MIO61 ? 30R MIO61_USB0_D5_OBDH

PS_MIO11
PS_MIO62 ? 30R MIO62_USB0_D6_OBDH

PS_MIO12 ? 30R MIO12_SPI0_PFM_OBDH_SCLK PS_MIO63 ? 30R MIO63_USB0_D7_OBDH

PS_MIO64 MIO64_RGMII_TX_CLK
PS_MIO13 ? 30RMIO13_SPI0_PFM_OBDH_/CS
PS_MIO65 MIO65_RGMII_TXD_0
PS_MIO14 ? 30R MIO14_SPI0_PFM_OBDH_/CS_1
PS_MIO66 MIO66_RGMII_TXD_1 Gigabyte Ethernet to Umbilicals
PS_MIO15 MIO15_SPI0_PFM_OBDH_EN and Payload (if required)
PS_MIO67 MIO67_RGMII_TXD_2
PS_MIO16 ? 30R MIO16_SPI0_PFM_OBDH_MISO
PS_MIO68 MIO68_RGMII_TXD_3
PS_MIO17 ? 30R MIO17_SPI0_PFM_OBDH_MOSI
PS_MIO69 MIO69_RGMII_TX_CTL
PS_MIO18 MIO18_I2C0_PFM_OBDH_SCL
PS_MIO70 MIO70_RGMII_RX_CLK
PS_MIO19 MIO19_I2C0_PFM_OBDH_SDA
PS_MIO71 MIO71_RGMII_RXD_0
PS_MIO20 MIO20_I2C0_PFM_OBDH_EN
PS_MIO72 MIO72_RGMII_RXD_1
PS_MIO21 MIO21_UART1_PLM_EN
PS_MIO73 MIO73_RGMII_RXD_2
PS_MIO22 MIO22_UART0_OBDH_RXD
PS_MIO74 MIO74_RGMII_RXD_3
PS_MIO23 MIO23_UART0_OBDH_TXD
PS_MIO75 MIO75_RGMII_RX_CTL
PS_MIO24 MIO24_UART1_PLM_TXD
MIO25_UART1_PLM_RXD PS_MIO76
R5_1V8_VCCO_PSIO PS_MIO25
PS_MIO77
R5_1V8_VCCO_PSIO
VCCO_PSIO0_500_0
B

VCCO_PSIO0_500_1
VCCO_PSIO2_502_0
VCCO_PSIO0_500_2
VCCO_PSIO2_502_1
GND
xczu4cg_sfvc784_1l_i GND
xczu4cg_sfvc784_1l_i

?
BANK 501

PS_MIO26
PS_MIO27
PS_MIO28
PS_MIO29
PS_MIO30
C

PS_MIO31
PS_MIO32
PS_MIO33
PS_MIO34
PS_MIO35
PS_MIO36
PS_MIO37
PS_MIO38
PS_MIO39
PS_MIO40
PS_MIO41
PS_MIO42
PS_MIO43
PS_MIO44
PS_MIO45 MIO45_SD1_DETECT
PS_MIO46 ? 30R MIO46_SD1_DATA0
PS_MIO47 ? 30R MIO47_SD1_DATA1
PS_MIO48 ? 30R MIO48_SD1_DATA2
PS_MIO49 ? 30R MIO49_SD1_DATA3
PS_MIO50 ? 30R MIO50_SD1_CMD
PS_MIO51 ? 30R MIO51_SD1_CLK
R5_1V8_VCCO_PSIO
Impedance matching SD1 LS (2.0) MIO[51:45]
VCCO_PSIO1_501_0
D

VCCO_PSIO1_501_1 GND

xczu4cg_sfvc784_1l_i

MODEL: PRODUCTE-FPGA BOARD SHEET 13 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ MIO BANKS
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

VDD_MB_5V PMIC_VDDIO_1V8 VDD_MB_5V PMIC_VDDIO_1V8

? 2R 2R
0.063W 1% ? 0.063W 1%

? ? ? ? ? ? ? ? ? ?
1uF 0.1uF 4.7uF 4.7uF 1uF 1uF 0.1uF 4.7uF 4.7uF 1uF
A

6.3V 16V 6.3V 6.3V 6.3V 6.3V 16V 6.3V 6.3V 6.3V

? ? GND ? ? GND
22uF 1uF GND 22uF 1uF GND
6.3V 6.3V 6.3V 6.3V

VCC

VCC
VDDIO

VDDIO
VSUPPLY

VDRV

VSUPPLY

VDRV
? ? R3_1V8_VCC_PSAUX ? ?
22uF 1uF 22uF 1uF R5_1V8_VCCO_PSIO
6.3V 6.3V 6.3V 6.3V
? 0.1uF ? ? 0.1uF ?
BOOT_A BOOT_A
VIN_A PHASE_A 10V 6.8uH 5A 20% VIN_A PHASE_A 10V 15uH 5A 20%
? ? ? ?
FB_A
220uF ? ? FB_A 220uF
47uF 1uF VIN_B PWM_A 6.3V 47uF 1uF VIN_B PWM_A 6.3V
6.3V 6.3V 6.3V 6.3V
RTN_A RTN_A
VIN_C ISEN_A+ VIN_C ISEN_A+

? ISEN_A- R4_1V2_VCC_PLL ISEN_A- R3_2V5_DDR_VPP

? VIN_D
? ? VIN_D
22uF 1uF ? 0.1uF ? GND 22uF 1uF ? 0.1uF ? GND
6.3V 6.3V BOOT_B 6.3V 6.3V BOOT_B
VIN_LDO ? PHASE_B 10V 3.3uH 5A 20%
? VIN_LDO ? PHASE_B 10V 22uH 5A 20%
?
10K 0.063W FB_B R1_0V72_VCCINT 10K 0.063W FB_B R2_0V85_VCC_PSINTLP 220uF
PMIC_SLEEP_N ? SLEEP#
220uF PMIC_SLEEP_N ? SLEEP#
0.5% ? 0.1uF ? 6.3V 0.5% ? 0.1uF ? 6.3V
PMIC_EN ? PMIC_EN ?
PMIC_IRPS5401_V0

PMIC_IRPS5401_V0
BOOT_C BOOT_C
EN_A PHASE_C 10V 2.2uH 5A 20% EN_A PHASE_C 10V 2.2uH 5A 20%
? EN_B FB_C
? ? EN_B FB_C
?
220uF 220uF
B

? EN_C 6.3V GND ? EN_C 6.3V GND

EN_D BOOT_D EN_D BOOT_D
GND ? EN_L PHASE_D
GND ? EN_L PHASE_D
? FB_D ? FB_D
SDA DATA GND SDA DATA GND
SCL CLK VO_LDO SCL CLK VO_LDO
ALERT# ALERT# FB_L ALERT# ALERT# FB_L

MTP PG_A MTP PG_A

ADDR_PROT PG_B ADDR_PROT PG_B
PG_C PG_C
? ? ? SYNC_CLK PG_D ? ? ? SYNC_CLK PG_D
?
AGND

AGND
2.32K ? ? 2.32K 2.87K ?
GND

GND
PG_L PG_L
10uF 2.32K 10uF
1V8

1V8
0.063W
6.3V 0.063W
10uF 10K 0.063W
6.3V
0.063W
1%
10uF 10K
1% 6.3V 0.063W 1% 6.3V 0.063W
1%
0.5% 0.5%
? ?
0.1uF 0.1uF
16V 16V

GND GND
GND GND
C

VDD_MB_5V THE REMOTE SENSING TERMINAL,

VTTSNS, SHOULD BE CONNECTED
TO THE POSITIVE TERMINAL OF THE
OUTPUT CAPACITOR(S) AS A
? ? SEPARATE TRACE FROM THE HIGH
1uF 0.1uF
10V 16V CURRENT PATH FROM THE VTT PIN

?
R4_1V2_VCC_PLL GND TPS51206 DDR_VTT
VDD

VDDQSNS VTT
VDD_MB_5V ? ? VLDOIN

10uF 1uF
VTTSNS DDR_VTT_REF
6.3V 6.3V S3
?
THRM_PAD

S5 VTTREF
10uF
? ? ? 6.3V
PGND

GND

10K 10K 0.22uF

1/10W
1%
1/10W
1%
GND 25V
D

GND

MODEL: PRODUCTE-FPGA BOARD SHEET 14 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: OBDH POWER SUPPLY (PMIC)
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

R1_0V72_VCCINT R3_1V8_VCC_PSAUX ? 1V8_VCC_PSDDR_PLL

120 Ohm @ 100 MHz
3A
? ? ? ? ? ? ? ? ? ? ? ? ? VCC_PSDDR_PLL
680uF 100uF 47uF 22uF 4.7uF 0.47uF 0.1uF VCCINT 10uF 100uF 22uF 4.7uF 0.47uF 0.1uF
6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 16V 6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND GND
A

? 1V8_VCC_PSADC
R2_0V85_VCC_PSINTLP 220 Ohm @ 100 MHz
2.5A
? ? ?
4.7uF 0.47uF 0.1uF VCCADC / VCC_PSADC
6.3V 6.3V 16V
? ? ? ? ? ?
100uF 100uF 47uF 22uF 4.7uF 0.1uF VCC_PSINTLP
6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND
GND

? ? ? ? ? ?
100uF 100uF 47uF 22uF 4.7uF 0.1uF VCC_PSINTFP / VCC_PSINTFP_DDR
6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND
B

? ? ? ? ?
100uF 47uF 47uF 4.7uF 0.1uF VCCINT_IO / VCCBRAM
6.3V 6.3V 6.3V 6.3V 16V

GND

R4_1V2_VCC_PLL

? ? ? ?
C

100uF 22uF 4.7uF 0.1uF VCC_PSPLL

6.3V 6.3V 6.3V 16V

R3_1V8_VCC_PSAUX GND

? ? ? ? ? VCC_PSAUX
100uF 47uF 4.7uF 4.7uF 0.1uF
6.3V 6.3V 6.3V 6.3V 16V ? ? ? ? ? ? ? ?
100uF 100uF 47uF 4.7uF 0.1uF 0.1uF 0.1uF 0.1uF
6.3V 6.3V 6.3V 6.3V 16V 16V 16V 16V

VCCO_PSDDR

GND GND

? ? ? ? ?
47uF
6.3V
47uF
6.3V
4.7uF
6.3V
4.7uF
6.3V
0.1uF
16V
VCCAUX / VCCAUX_IO
D

GND

MODEL: PRODUCTE-FPGA BOARD SHEET 15 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ DECOUPLING CAPACITORS #1
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

R5_1V8_VCCO_PSIO

? ? ? ? ? ? ? ?
100uF 100uF 47uF 4.7uF 4.7uF 4.7uF 4.7uF 0.1uF BANK 500
6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 16V
A

GND

? ? ? ? ? ? ? ?
100uF 100uF 47uF 4.7uF 4.7uF 4.7uF 4.7uF 0.1uF BANK 501
6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND

? ? ? ? ? ? ? ?
100uF 100uF 47uF 4.7uF 4.7uF 4.7uF 4.7uF 0.1uF BANK 502
6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND
B

? ? ? ? ? ? ? ?
100uF 100uF 47uF 4.7uF 4.7uF 4.7uF 4.7uF 0.1uF BANK 503
6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 6.3V 16V

GND

? ? ? ? ?
47uF 47uF 4.7uF 4.7uF 0.1uF VCCO_HP_B66
6.3V 6.3V 6.3V 6.3V 16V

GND
C

? ? ? ? ?
47uF 47uF 4.7uF 4.7uF 0.1uF VCCO_HP_B65
6.3V 6.3V 6.3V 6.3V 16V

ONE PER BANK.

GND USED BANKS: 66, 65, 64, 43

NOT USED BANKS: 46, 45, 44

? ? ? ? ?
47uF 47uF 4.7uF 4.7uF 0.1uF VCCO_HP_B64
6.3V 6.3V 6.3V 6.3V 16V

GND
D

? ? ? ? ?
47uF 47uF 4.7uF 4.7uF 0.1uF VCCO_HD_B43
6.3V 6.3V 6.3V 6.3V 16V

GND

MODEL: PRODUCTE-FPGA BOARD SHEET 16 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: ZYNQ DECOUPLING CAPACITORS #2
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

VDD_MB_5V VDD_MB_5V VDD_MB_5V VDD_MB_5V

? ? ?
1 2 1 2 1 2
3 4 B66_E5_SDR_RX_D3_P 3 4 MIO7_OBDH_GPIO_2 3 4
5 6 B66_D5_SDR_RX_D3_N PMIC_VDDIO_1V8 5 6 MIO8_OBDH_GPIO_3 5 6 MIO45_SD1_DETECT
7 8 7 8 MIO6_OBDH_GPIO_1 7 8
9 10 9 10 MIO5_OBDH_GPIO_0 9 10 MIO48_SD1_DATA2
B66_G8_SDR_RX_D4_P 11 12 11 12 PMIC_EN MIO9_OBDH_GPIO_4 11 12
B66_F7_SDR_RX_D4_N 13 14 13 14 13 14 MIO49_SD1_DATA3
15 16 B66_G6_SDR_RX_D5_P 15 16 PMIC_SLEEP_N MIO3_CAN0_TX_OBDH 15 16
17 18 B66_F6_SDR_RX_D5_N 17 18 17 18 MIO50_SD1_CMD
19 20 19 20 B65_H9_HK_I2C_SDA MIO0_CAN0_STBY_OBDH 19 20
21 22 21 22 21 22 MIO46_SD1_DATA0
B66_E4_SDR_RX_FRAME_P 23 24 23 24 B65_R8_HK_I2C_ALERT_N MIO2_CAN0_RX_OBDH 23 24
B66_E3_SDR_RX_FRAME_N 25 26 25 26 25 26 MIO47_SD1_DATA1
27 28 B66_G5_SDR_TX_D5_P 27 28 B65_K9_HK_I2C_SCL MIO16_SPI0_PFM_OBDH_MISO 27 28
29 30 B66_F5_SDR_TX_D5_N 29 30 29 30 MIO51_SD1_CLK
31 32 31 32 MIO17_SPI0_PFM_OBDH_MOSI 31 32
33 34 33 34 33 34 B43_AH11_USB0_PWR_SW
B66_D4_SDR_TX_D4_P 35 36 35 36 MIO13_SPI0_PFM_OBDH_/CS 35 36
B66_C4_SDR_TX_D4_N MIO62_USB0_D6_OBDH
B

37 38 37 38 37 38
39 40 B66_G3_SDR_TX_D3_P 39 40 MIO12_SPI0_PFM_OBDH_SCLK 39 40 MIO57_USB0_D1_OBDH
41 42 B66_F3_SDR_TX_D3_N 41 42 41 42
43 44 43 44 MIO15_SPI0_PFM_OBDH_EN 43 44 MIO55_USB0_NXT_OBDH
45 46 45 46 45 46
B66_B3_SDR_TX_D2_P 47 48 47 48 MIO14_SPI0_PFM_OBDH_/CS_1 47 48 MIO56_USB0_D0_OBDH
B66_A3_SDR_TX_D2_N 49 50 49 50 49 50 MIO60_USB0_D4_OBDH
51 52 B66_E1_SDR_TX_D1_P 51 52 B503_PS_INIT_B 51 52
53 54 B66_D1_SDR_TX_D1_N 53 54 B66_A6_USB_RST 53 54 MIO53_USB0_DIR_OBDH
55 56 55 56 B503_PS_ERROR_STATUS 55 56
57 58 57 58 57 58 MIO59_USB0_D3_OBDH
B66_G1_SDR_TX_D0_P 59 60 59 60 B43_AA10_SDR_RST_N B503_PS_ERROR_OUT 59 60 MIO61_USB0_D5_OBDH
B66_F1_SDR_TX_D0_NTX_D0_N 61 62 B43_AA11_SDR_MOSI 61 62 61 62
63 64 B66_C3_SDR_FB_CLK_P 63 64 B43_AA8_SDR_EN 63 64 MIO63_USB0_D7_OBDH
65 66 B66_C2_SDR_FB_CLK_N B43_AB11_SDR_SPI_CS_N 65 66 MIO25_UART1_PLM_RXD 65 66 MIO54_USB0_D2_OBDH
67 68 67 68 B43_Y9_SDR_EN_AGC MIO21_UART1_PLM_EN 67 68
69 70 B43_AC11_SDR_CNTRLO_3 69 70 MIO24_UART1_PLM_TXD 69 70 MIO58_USB0_STP_OBDH
B66_D7_SDR_DATA_CLK_P 71 72 71 72 B43_Y10_SDR_CNTRLI_1 71 72
B66_D6_SDR_DATA_CLK_N 73 74 B43_AB9_SDR_SPI_CLK 73 74 MIO19_I2C0_PFM_OBDH_SDA 73 74 MIO52_USB0_CLK_OBDH
75 76 B66_F2_SDR_TX_FRAME_P 75 76 B43_W10_SDR_CNTRLI_2 MIO20_I2C0_PFM_OBDH_EN 75 76
77 78 B66_E2_SDR_TX_FRAME_N B43_AB10_SDR_MISO 77 78 MIO18_I2C0_PFM_OBDH_SCL 77 78 B66_E8_USART_OBDH_RX
79 80 79 80 B43_AF11_SDR_CNTRLO_4 79 80
81 82 B43_AG11_SDR_CNTRLO_2 81 82 B66_A9_RS485_RX_RO 81 82 B66_E9_USART_OBDH_RTS
B66_C1_SDR_RX_D1_P 83 84 83 84 B43_AF12_SDR_CNTRLI_3 83 84
B66_B1_SDR_RX_D1_N 85 86 B43_AE10_SDR_CNTRLI_0 85 86 B66_B9_RS485_RX_/RE 85 86 B66_D9_USART_OBDH_CK
B66_G1_SDR_RX_D0_P B43_AE12_SDR_CNTRLO_5
C

87 88 87 88 87 88
89 90 B66_F1_SDR_RX_D0_N B43_AF10_SDR_CNTRLO_6 89 90 B66_A8_RS485_TX_DE 89 90 B66_C9_USART_OBDH_CTS
91 92 91 92 B43_AD12_SDR_CNTRLO_7 91 92
93 94 B43_AD11_SDR_TX_RX 93 94 B66_B8_RS485_TX_DI 93 94 B66_C8_USART_OBDH_TX
B66_A2_SDR_RX_D2_P 95 96 95 96 B43_AC12_SDR_CNTRLO_1 95 96
B66_A1_SDR_RX_D2_N 97 98 B43_AD10_SDR_CNTRLO_0 97 98 B66_A7_RS485_RX_/SLO 97 98
99 100 99 100 99 100 DETECT_OBDH

J1 J2 JMIO

GND GND GND GND GND GND

D

MODEL: PRODUCTE-FPGA BOARD SHEET 17 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: HARNESS INTERFACE I
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
 1 2 3 4 5 6 7

VDD_MB_5V VDD_MB_5V
?
?
MIO64_RGMII_TX_CLK 1
MIO65_RGMII_TXD_0 1 2
2
3 4 B64_AF7_L11_P
MIO66_RGMII_TXD_1 3 Bootstap/jumpers resistors
5 6 B64_AF6_L11_N
MIO67_RGMII_TXD_2 4 (included on EVB from TI DP83867IRPAP)
7 8
MIO68_RGMII_TXD_3 5
9 10
MIO69_RGMII_TX_CTL 6
B64_AD5_L13_P 11 12
MIO70_RGMII_RX_CLK 7
B64_AD4_L13_N 13 14
MIO71_RGMII_RXD_0 8
15 16 B64_AE5_L12_P
MIO72_RGMII_RXD_1 9
17 18 B64_AF5_L12_N
MIO73_RGMII_RXD_2 10
19 20
MIO74_RGMII_RXD_3 11
21 22
MIO75_RGMII_RX_CTL 12
B64_AE2_L22_P 23 24
13
B64_AF2_L22_N 25 26
27 28 B64_AG9_L7_P
B64_AH9_L7_N
GND JRGMII (Ethernet) 29
31
30
32
33 34
B64_AE3_L21_P 35 36
B64_AF3_L21_N
B

37 38
39 40 B64_AF8_L8_P
41 42 B64_AG8_L8_N
43 44
45 46
B64_AB2_L17_P 47 48
B64_AC2_L17_N 49 50
51 52 B64_AH8_L9_P
53 54 B64_AH7_L9_N
55 56
57 58
? B64_AB1_L18_P 59 60
MIO22_UART0_OBDH_RXD 1 B64_AC1_L18_N 61 62
MIO23_UART0_OBDH_TXD Null modem B64_AG6_L10_P
2 63 64
(without handshaking) B64_AG5_L10_N
3 65 66
67 68
69 70
JUART B64_AD2_L16_P 71 72
GND B64_AD1_L16_N 73 74
75 76 B64_AG4_L19_P
77 78 B64_AH4_L19_N
79 80
81 82
B64_AF1_L24_P 83 84
B64_AG1_L24_N 85 86
B64_AG3_L20_P
C

87 88
89 90 B64_AH3_L20_N
91 92
93 94
R3_1V8_VCC_PSAUX B64_AH2_L23_P 95 96
B64_AH1_L23_N 97 98
99 100

? ? ? ? J3
4.7K 4.7K 4.7K 4.7K
? 1/16W 1/16W 1/16W 1/16W
1.5< VREF < 5VDC 1% 1% 1% 1%
1 2
3 4 JTAG_TMS
5 6 JTAG_TCK
7 8 JTAG_TDO
9 10 JTAG_TDI GND GND
11 12 NC
13 14 NC

JTAG
GND
D

MODEL: PRODUCTE-FPGA BOARD SHEET 18 OF 18

DRAWN C.SIERRA/A.CASAS TITLE: HARNESS INTERFACE II
VERSION: 1.1
SIZE:A4

CHECKED D.ROMA/J.G.CAMA DRAWING NO.: SCH P/N: 01, PCB P/N: 01, ASSY P/N: 01, TEST P/N: 01
94 Design and integration of a MP-OBC with SDR for nano-satellites

F OBC stand-alone version datasheet

The following pages will present the datasheet assembled for the stand-alone version of
the C3 SatP system.
 C3SatP System

OBC Stand-alone
Datasheet
On-board Computer System for mission critical space applications

Version 1.1
C3SatP System: OBC

Contents
Introduction ....................................................................................................................................................................4
Overview ........................................................................................................................................................................4
1. Highlighted features ..........................................................................................................................................5
2. Block Diagram...................................................................................................................................................6
Functional Description....................................................................................................................................................7
1. Theory of operation ...........................................................................................................................................7
2. Microcontroller ..................................................................................................................................................7
3. CAN Interface ...................................................................................................................................................8
4. UART Interface .................................................................................................................................................8
5. SPI Interface .....................................................................................................................................................9
6. I2C Interface ......................................................................................................................................................9
6.1 External ..........................................................................................................................................................9
6.2 Internal.......................................................................................................................................................... 10
7. Inertial Measurement Unit (IMU) ..................................................................................................................... 10
8. Micro-SD memory card ................................................................................................................................... 11
9. External Watchdog .......................................................................................................................................... 11
10. RF Transceiver ........................................................................................................................................... 12
11. USART Interface ........................................................................................................................................ 12
12. Serial Wire Debug (SWD) ........................................................................................................................... 12
13. Power Management Integrated Circuit (PMIC) ........................................................................................... 12
General Characteristics................................................................................................................................................ 14
Absolute maximum ratings ........................................................................................................................................... 17
Physical Characteristics ............................................................................................................................................... 17
Environment Testing .................................................................................................................................................... 17
Hardware Layout, Connectors and Pinouts .................................................................................................................. 18
1. PCB Layout ..................................................................................................................................................... 18
1.1 OBC Top....................................................................................................................................................... 18
1.2 OBC Bottom ................................................................................................................................................. 18
2. Connectors mapped to STM32 ....................................................................................................................... 19
2.1 J1, J2 – RF Transceiver connectors ............................................................................................................. 19
2.2 J3 – Serial Wire Debug header..................................................................................................................... 19
2.3 J4 – SD memory card holder ........................................................................................................................ 19
2.4 J5 – I²C connector ........................................................................................................................................ 20
2.5 J6 – SPI connector ....................................................................................................................................... 20
2.6 J7 – Power connector ................................................................................................................................... 20
2.7 J8 – CAN connector...................................................................................................................................... 21
2.8 JX(TBD) – UART connector ......................................................................................................................... 21
Software Development ................................................................................................................................................. 22
Mechanical Drawings ................................................................................................................................................... 23
References ................................................................................................................................................................... 24
Ordering Form .............................................................................................................................................................. 25

2
C3SatP System: OBC

Revision History
Issue Release Date Page Description of change Comments
1.0 24/04/2019 All First Release -
1.1 20/6/2019 All Corrected minor issues: -
- 1,4 seconds watchdog timeout
(section 9)
- Added UART bitrates in electrical
specs, as stated in MCU datasheet.
- Removed misleading power
information in General Characteristics
section.
- Clarified UART TX and RX directions
(2.8)

3
C3SatP System: OBC

Introduction
The C3SatP On-Board Computer is a versatile and reliable processing module based on the
STM32 microcontroller for small satellite missions, with a form factor designed to be easily
integrated in commercial CubeSat structures. Without the cumbersome PC104 connector, it
allows the use of only the needed subsystems I/Fs, saving space, weight and the typical pinout
mismatches of other commercial boards used in the mission. It also plays the role of a
motherboard (allows the connection of 2 “expansion” boards), to increase its processing and
communication capabilities, if required.

This board is part of the C3SatP system, which can be acquired with 3 different
configurations:

● Single Motherboard: C3SatP OBC stand-alone option.

● Motherboard + OBDH for demanding applications: C3SatP OBC + OBDH option.
● Complete C3SatP: C3SatP OBC + OBDH + SDR communications option.

Further modifications required by your mission (pull-up resistors, terminations, software toolkit,
etc) can also be chosen in the Ordering Form (at the end of this document).

This document will only explain the characteristics of the OBC as stand-alone board. Connectors
and components that are controlled/used by the daughterboards OBDH and SDR only, but rest
on OBC’s board, will be excluded. For the complete system, please refer to the C3SatP System
datasheet.

Overview
The OBC contains 5 main parts:

• The on-board computer (based on a STM32 microcontroller), designed as an efficient

system for space applications with limited resources.
• An inertial measurement unit (based on BNO055 component) with 9 DOF: 3-Axis
magnetometer, 3-axis gyroscope and 3-axis accelerometer.
• A TX/RX RF transceiver, between 300-1000 MHz, based on the CC1101 transceiver.
• A SD card of up to 32 GB acting as mass memory.

The OBC has available several communications buses to interface with external subsystems such
as CAN, SPI and I2C. It also uses an I2C bus for HK purposes (isolated from external
subsystems), which is compatible with PMBus commands and its fault management. The STM32
can be configured to work with different clock speeds (between 24 and 160 MHz) and use up to
its 512 Kb of FLASH memory.

The OBC board allows the interconnection of the C3SatP daughterboards through its high density
high speed connectors. These boards improve the system capability in terms of processing power
(with the addition of the Zynq Ultrascale+ MPSoC), communication protocols (RS-485, UART,
USB, etc. will be available to interface other subsystems), and RF communications (thanks to the
SDR). Even without the expansion boards, the OBC can receive telecommands from ground,
perform its tasks, and transmit the results to ground with outstanding reliability.

4
C3SatP System: OBC

1. Highlighted features
● High-performance STM32F446RE with advanced power saving features
○ Clock frequency configurable from 24 MHz to 160 MHz.
○ 512 kB build-in flash
○ 128 kB build-in RAM
○ IEEE 754 FPU
○ Internal Real Time Clock
○ External watchdog implemented
○ Multiple protocol communication (CCSDS/PUS, CSP) over data interfaces: I2C, UART,
CAN or SPI (2 chip select).

● 9 DoF Inertial Measurement Unit (Bosch BNO055)

○ Data fusion capabilities (Quaternions, Euler angles, Rotation vector, etc)
○ 16-bit, 3-Axis gyroscope with ±125°/s to ±2000°/s selectable ranges.
○ 14 bit, 3-Axis accelerometer with ±2g/±4g/±8g/±16g selectable ranges.
○ ~12-bit, 3-Axis magnetometer with ±1300µT (x and y axis) and ±2500µT (z axis).

● Low power 433 MHz transceiver (Texas instruments CC1101)

○ Configurable baseband modem (2-FSK, 4-FSK, GFSK, MSK, OOK and flexible ASK)
○ Up to 600 kbps data rate
○ Programmable transmission power up to +10 dBm

● SD memory card
○ SDHC compatible (SD specification version 2.0)
○ Up to 32 GB capacity (FAT 12/16/32 format compatible)
○ Shared with OBDH (for the Linux OS image), if present.

● Dedicated internal I2C bus

○ PMBus compatible
○ Up to 400 kbps data rate.
○ Used to gather HK data from smart power regulators (V, I, W, T and faults) and the
IMU and control/configure its behavior.
○ If daughterboards are present, it will also gather their HK data or control/configure
(OBDH power and MPSoC status, as well as SDR power and system status).

● Suitable for standard commercial Cubesats.

○ ~1/8 U height (~0.5 U if daughter boards are present)
○ Low power consumption: < 1 W at full operation
○ Operational temperature: -40 °C to +85 °C

5
C3SatP System: OBC

2. Block Diagram

Figure 1: Block diagram of the OBC board, in the Complete C3SatP System configuration.

Figure 2: Block diagram of the Stand-alone version of the OBC board.

6
C3SatP System: OBC

Functional Description

1. Theory of operation
Once the CubeSat is released and the EPS provides 5 V to the Power Management Integrated
Circuit (PMIC), it starts the power on sequence and generates the proper voltages for the MCU
and its peripherals for nominal operation. The MCU then boots from the selected configuration
available in the SD card and enters in start-up mode during some predetermined time. After that,
and depending on the mission, the OBC will typically communicate with some of its subsystems
to operate them autonomously and perform the required tasks to ensure a safe state (detumbling,
solar panels deployment, antennas deployment, etc.)

Once in safe state and antennas are deployed, the OBC will start beaconing (to ease tracking the
satellite). The system will remain in this state, without performing any other operation, until the
first telecomm from ground is received, and the mission begins.

After Commissioning phase (self-health test, subsystems diagnosis, etc.), on operative state,
system will nominal do the mission needs managed by the payload processing implementation
under autonomous behavior of the OBC code (Status monitoring, ground communications, FDIR,
etc.).

2. Microcontroller
OBC’s MCU is based on a STM32F446RE from STMicroelectronics [1], with a high-performance
ARM® Cortex®-M4 32-bit RISC core, operating at a frequency up to 160 MHz. It features a single
precision Floating Point Unit (FPU) which supports all ARM® single-precision data-processing
instructions and data types. It also implements a full set of DSP instructions, high-speed
embedded memories (Flash memory up to 512 Kbyte, up to 128 Kbyte of SRAM) and an extensive
range of enhanced I/Os and peripherals connected to two APB buses, two AHB buses and a 32-
bit multi-AHB bus matrix. Specifically, the MCU has available to control and communicate with:

● 1 CAN bus for platform or payload I/F.

● 1 UART bus for debugging purposes or as peripheral I/F.
● 1 SPI bus (the MCU acting as master) with 2 Chip Selects.
● 1 RF Communication Link to ground, with a robust TM&TC architecture.
● 1 I2C (external) bus for platform or payload I/F.
● 1 I2C/PMB (internal) bus (with PMBus #Alert line) connected to the IMU and PMICs.
● 1 micro-SD card I/Fs (Up to 32 GB, shared with the OBDH Linux OS image, if present).

The MCU can be programed and debugged with its Serial Wire Debug (SWD) I/F, accessible
through the connector J3. The software package provided will cover the basic functionalities to
communicate and operate OBC and its peripherals (RF transceiver, IMU, SD, I2C, CAN, etc,
please refer to SW section 9).

7
C3SatP System: OBC

3. CAN Interface
One of the main interfaces of the OBC to communicate with critical subsystems is a CAN bus
interface (with the PicoBlade connector J8, see figure 1). The Controller Area Network (CAN) is
a serial communications protocol that supports distributed real-time control with a high level of
security.

The system uses the TLE7251V as a CAN transceiver [2], for both OBC’s MCU and OBDH Zynq.
Acting as an interface between the physical bus layer and the MCU, the transceiver drives the
signals to the bus and protects the controller against interferences generated within the network.
Based on the high symmetry of the CANH and CANL signals, the TLE7251V provides a very low
level of electromagnetic emission (EME) within a wide frequency range. It also provides excellent
ESD immunity together with a very high electromagnetic immunity (EMI). It is designed to fulfill
the enhanced physical layer requirements for CAN FD and supports data rates up to 2 MBit/s. It
also features short circuit proof to ground, battery and VCC, low CAN bus leakage current in
power-down state as well as over-temperature and transient protections.

The user can select the termination resistor value for improved performance, at the Ordering Form
(see appendix), or leave the one by default, a 120 Ω resistor. It is also possible to select the
addition of the libraries required to implement the CubeSat Space Protocol (CSP) using CAN as
the physical layer (for more information, see refer to Software Development section).

4. UART Interface
A UART is provided for debugging the MCU, although it could also be reconfigured to
communicate with other subsystems in the satellite. Users can access this interface through the
PicoBlade connector JX (reference TBD, see figure 1).

The bus voltage can be selected in the Ordering Form between 1.8V, 3.3V and 5V. Other
parameters will remain as in default configuration, listed hereunder:

Field Value
VDD_IO 1.8 V
Baud Rate 115200
Data bits 8
Parity None
Stop bits 1

Warning: please use only a physical layer transceiver of the appropriate voltage for
UART communications. Applying a digital signal of higher tension than the selected
voltage can cause irreversible damage to the MCU UART controller and/or the
transceiver.

8
C3SatP System: OBC

5. SPI Interface
A Serial Peripheral Interface (SPI) is provided to interconnect up to 2 subsystems to the OBC.
Users can access this I/F through the PicoBlade connector J6 (see figure 1).

The MCU will act as a master in an independent slave topology (2 slave select lines available),
as default. The SPI can be configured to perform full-duplex and simplex communications at up
to 22.5 Mbits/s. It features a 3-bit prescaler giving 8 master mode frequencies and a configurable
frame of 8 or 16 bits. It features Rx and TX FIFOs and a hardware CRC generation/verification,
which supports basic SD Card/MMC modes.

The bus voltage can be selected in the Ordering Form between 1.8V, 3.3V and 5V. Other
parameters will remain as in default configuration, listed hereunder:

Field Value
VDD_IO 3.3 V
CLK freq 22.5 MHz
CRC enabled

6. I2C Interface
The system comprises 2 independent Inter-Integrated Circuit (I2C) buses: one to communicate
with other satellite subsystems/payloads (External) and one for Housekeeping purposes
(Internal). The external bus can be accessed through the PicoBlade connectors J5 (see figure 1).

6.1 External

The I²C can support the standard (up to 100 kHz) and fast (up to 400 kHz) modes, the 7/10-bit
addressing mode and the 7-bit dual addressing mode (as slave). the MCU includes a hardware
CRC generation/verification, an analog filter capable of suppressing spikes of less than 50 ns,
and a configurable digital filter capable of suppressing spikes of up to 15 CLK cycles (for more
information, please read STM32 datasheet [1]).

The bus voltage can be selected in the Ordering Form between 1.8V, 3.3V and 5V. The user can
also choose to remove the pull-up resistors from OBC board, or otherwise, select their value for
improved performance or leave the ones by default, a 4.7 kΩ resistor. Other parameters will
remain as in default configuration, listed hereunder:

Field Value
VDDio 3.3 V
SCL frequency 100 kHz
Addressing bits 7
CRC disabled
Analog filter enabled
Digital filter disabled
Pull-up resistor 4.7 kΩ

9
C3SatP System: OBC

6.2 Internal

The internal I²C/PMBus bus is designed to interface all components within the C3SatP System
capable of providing Housekeeping telemetry, such as the smart power regulators (PMICs) or the
IMU. It will also gather information of daughterboard’s PMICs (both SDR and OBDH) and the
Zynq (in OBDH), if present. It does not have a connector since it is designed to gather HK data
from the OBC and its daughterboards only.

The basic software package provided is able to automatically gather all available HK information
and store it, or use it for payload purposes. The SW is also able to modify the behavior of the IMU
and the PMICs, writing in specific control registers.

The full set of IMU’s configuration registers are available to the user, but only a restricted set of
PMICs’ configuration registers can be modified (with the Platinum software distribution), in order
to reduce risks. Furthermore, the MCU will constantly rewrite PMICs registers with a valid and
safe configuration to reduce the risk of irreversible damage due to SEU issues in its registers. For
more information regarding these components and their configuration registers, please see
sections 7 (IMU) and 13 (PMIC).

Warning: Modifying restricted PMIC registers may cause irreversible damage to

OBCs’ electronics (even OBDH and SDR subsystems). Proceed at your own risk.

7. Inertial Measurement Unit (IMU)

The OBC includes a 9 degrees of freedom Inertial Measurement Unit from Bosch (BNO055, [3]).
It integrates a triaxial 14-bit accelerometer to measure the forces acting upon the satellite, a
triaxial 16-bit gyroscope to measure its rotations and a triaxial ~12-bit geomagnetic sensor.
Thanks to its 32-bit cortex M0+ embedded microcontroller running Bosch Sensortec software, this
IMU can provide the system with fused sensor data such as Quaternions, Euler angles, Rotation
vectors, Heading, etc. freeing computational resources of the OBC’s MCU. It also features a
power management unit to efficiently turn on and off each of the sensors for every mode of
operation (see table 1).

Table 1. IMU modes of operation.

10
C3SatP System: OBC

The IMU can be accessed through the HK I2C /PMBus bus at the 0x28 address. Its position in the
board as well as the default definition of its sensor axis can be seen in Figure 3. Distances shown
are measured from IMU’s centroid (marked with an X) to OBC’s PCB centroid (also market with
an X). For more information regarding the position of different OBC’s components and connectors
can be found in the section 11 (Mechanical Drawings).

Figure 3. OBC boar top view with the IMU reference frame.

8. Micro-SD memory card

The system incorporates a micro-SD card holder that can accept SDHC cards (SD specification
2.0) up to 32 GB capacity with a FAT 32 format. The board comes from factory with a formatted
SD with the basic configuration file.

The MCU will have full access to the mass memory except if the OBDH daughterboard is
integrated in the system, since its storage needs will be more demanding (OBDH requires a Linux
OS image to operate). In this situation of shared memory, before OBC commands the PMIC’s to
power-on the OBDH electronics, OBC will give the full control of the SD to the OBDH system (For
more information regarding this mode of operation please refer to the C3SatP System Datasheet).
In order for the OBC to access to data storage, if necessary, it will do so through a high level
communication between OBC and OBDH using the USART interface in connector J15 (For more
information regarding USART interface, please refer to the C3SatP Software Manual).

9. External Watchdog
The OBC’s MCU power line and heartbeat will be monitored with an external watchdog from
Analog Devices (ADM6823). The ADM6823 will force a reset if the MCU’s VCC input goes lower
than 1.67 V. MCU’s software must provide a pulse bigger than 50 ns every 1,40 s to avoid a
watchdog reset.

11
C3SatP System: OBC

10. RF Transceiver
The system includes a simple but reliable radio-communications link to ground (400 - 450 MHz)
thanks to its RF transceiver CC1101, from Texas instruments [4], designed for very low-power
wireless applications. The transceiver is integrated with a highly configurable baseband modem
which supports various modulation formats (2-FSK, 4-FSK, GFSK, MSK, OOK and ASK) and has
a configurable data rate from 0.6 kbps up to 600 kbps. The CC1101 provides extensive hardware
support for packet handling, data buffering, burst transmissions, clear channel assessment, link
quality indication, and wake-on-radio. For more information on the transceiver specifications,
please see General Characteristics section.

Users can connect to Rx and Tx lines at the Amphenol SMPM coaxial jacks J1 and J2 (for more
information, see Hardware Layout section)

The software provided includes the libraries required to communicate with the transceiver using
a dedicated SPI bus of the MCU. A higher level communication protocol has also been
implemented. For more information regarding SW implementation and communications protocols,
please refer to the C3SatP Software Manual.

11. USART Interface

The OBC’s MCU includes a Universal Synchronous Asynchronous Receiver-Transmitter
(USART) interface with the OBDH as the internal communication bus between the two systems.
At boot up, the MCU will enable this interface if it detects that the OBDH is present.

Using this interface, the OBC Software will monitor and control the OBDH Core software using
mainly the CCSDS/PUS protocol, and share data at up to 11.25 Mbits/s (TBC).

12. Serial Wire Debug (SWD)

The board incorporates a SWD connector to load the firmware of the STM32 MCU. Together with
the UART connection, they are the two main options for debugging the MCU and its peripherals.
For more information about the connector’s pinout, please see section 3. For more information
regarding SWD and UART protocols, please see section 9 and the STM32 datasheet [1].

13. Power Management Integrated Circuit (PMIC)

The system incorporates an efficient smart switched power regulator IRPS5401, from Infineon [5].
It provides digital telemetry and incorporates over and under voltage, over-current as well as over-
temperature protections. This PMIC has an I²C/PMBus interface for control and telemetry
purposes, which is connected to OBC’s HK I²C/PMBus bus. Its configuration can be modified via
software to better fit every satellite mode of operation, reaching up to 85% efficiency.

The basic firmware provided is able to gather HK data from it, such as voltage levels, currents
and temperature, but also warnings and failures thanks to its PMBus #Alert line. For the OBC,
their set of configurations will be predefined (no modifications in-flight allowed) throughout the

12
C3SatP System: OBC

entire mission to increase reliability, with the protections dimensioned for the highest power
demand possible (see power modes in table 2). When powered with a 5V input, PMIC’s safest
configuration will be loaded from an intern OTP memory to then boot the MCU and its peripherals.
To increase reliability during nominal operations, the MCU will constantly rewrite PMICs registers
with a valid and safe configuration from the SD card to reduce the risk of irreversible damage due
to SEU issues in its registers.

Its I²C address is 0x16 and its PMBus address is 0x46.

When present, OBDH and SDR daughter boards’ PMICs will also be connected to the HK bus to
provide their telemetry and a way to operate them from the MCU. With this topology, the OBC’s
MCU will be in charge of turning on and off each of the daughterboards as well as to reconfigure
OBDH PMICs for every mode of operation (or application).

Typical power Maximum power

OBC mode Peripherals ON
(mW) (mW)
Booting MCU, SD 377 649
IDLE MCU(1) 281 458
Receiving TC MCU, RF-Rx 383 660
Transmitting TM MCU, RF-Tx 387 696
Science (IMU) MCU, SD, IMU 433 733

Science (I2C & SPI) RF-Rx(2), MCU, SD, I2C, SPI 412 691

Science (CAN) RF-Rx(2), MCU, SD, CAN 608 992

Full operation RF-Rx(2), MCU, SD, I2C, SPI, CAN, IMU 671 1061

(1) MCU clock reduced to 60 MHz.

(2) RF transceiver in low power “listening” mode.

Table 2. OBC power consumption by mode of operation.

13
C3SatP System: OBC

General Characteristics
Parameter Condition Min Typ. Max Unit
On-Board Computer system
Supply Voltage On connector J7 4.85 5.00 5.15 V
Total current At VDD 5V, CLK at 60 MHz, mA
PMIC 65% eff
50 112 212
Operating temperature -40 - 85 °C
MCU Clock Frequency STM32 24 60 160 MHz
CC1101 - RF Transceiver

Frequency range 387 433 464 MHz

Data rate 0.6 600 kbit/s
Tx Power +10 dBm
Rx sensitivity at (0.6kbit/s) -116 dBm
Current Rx (mode) 433MHz 1.2 kbit/s 16 mA
Current Tx (mode) 433MHz +10dBm 29.2 mA
Spurious emissions Rx (25 MHz - 1GHz) -68 -57 dBm
Spurious emissions Tx 1st Harm. 433 MHz -49 dBm
2nd Harm. 433 MHz -40 dBm
3rd Harm. 433 MHz -40 dBm
BNO055 - IMU Magnetometer
Field range X and Y axis ±1.2 ±1.3 mT
Z axis ±2.0 ±2.0 mT
Data rate 2 10 30 Hz
Resolution ADC 11 12 13 bits
Sensor 0.3 µT
BNO055 - IMU Gyroscope
Full-Scale Range ±125 ±500 ±2000 °/s
Data rate 12 64 523 Hz
Resolution ADC 16 bit
Sensor 6.8 28.4 109.8 “/s / LSB
Nonlinearity ±0.05 ±0.2 %FS

General Characteristics (continued)

14
C3SatP System: OBC

Parameter Condition Min Typ. Max Unit

BNO055 - IMU Accelerometer
Full-Scale Range ±2 ±8 ±16 g
Band Width Accelerometer 7.81 125 1000 Hz
Digital filter 8 125 1000 Hz
Resolution 14 bits
122 488 977 µg / LSB
Nonlinearity 0.5 2 %FS
Cross-Axis Sensitivity relative contribution between 1 2 %
any two of the three axes
I2C
VDDio Through level shifter 3.2 3.3 3.4 V

Bypassing level shifter 1.75 1.8 1.85 V

With the 5V option 4.85 5 5.15 V

Low level voltage -0.1 0 0.1 V

Bit-rate 100 - 400 kbit/s

Bus lines capacity - 300 400 pF
Power Consumption IO driving at a given bit rate mW
MCU's SPI controller on mW
SPI
VDDio Through level shifter 3.2 3.3 3.4 V
Bypassing level shifter 1.75 1.8 1.85 V
With the 5V option 4.85 5 5.15 V
Low level voltage -0.1 0 0.1 V
SS high level voltage VDDio - VDDio + V
VDDio
3% 3%
SS low level voltage -0.1 0 0.1 V
Bit-rate - - 22.5 Mbit/s
Power consumption IO driving at a given bit rate - 6,9 11,9 mW
MCU's SPI controller on - 0,15 0,29 mW

15
C3SatP System: OBC

General Characteristics (continued)

Parameter Condition Min Typ. Max Unit
CAN
Bus voltages CAN H "Dominant" 2.75 - 4.5 V
CAN L "Dominant" 0.5 - 2.25 V
CAN H / CAN L "Recessive" 2.0 2.5 3.0 V
Bit-rate - 1 2 Mbits / s
Power consumption Transceiver in Normal-operation 16,3 193,3 303,3 mW
Transceiver in Stand-by mode 0,01 0,05 0,07 mW
MCU's CAN controller on 1,35 2,24 4,30 mW
UART
High level voltage Through level shifter 3.2 3.3 3.4 V
Bypassing level shifter 1.75 1.8 1.85 V
With the 5V option 4.85 5 5.15 V
Low level voltage -0.1 0 0.1 V
Bit-rate min with x16 oversampling. Mbit/s
max with x8 oversampling.
5.62 11.25

16
C3SatP System: OBC

Absolute maximum ratings

Stresses above those listed under Absolute Maximum Ratings may cause permanent damage
to the OBC. Exposure to absolute maximum rating conditions for extended periods may affect
the reliability.

Symbol Description Min. Max. Unit

VCCobc Supply voltage 4.85 5.15 V
Iobc Supply current 0 1 A
Tamb Operating Temperature -40 85 °C
Tstg Storage Temperature -40 85 °C
Vio_sbus Voltage on I2C/SPI/UART pins -0.5 6.5 V
Vio Voltage on SWR pins -0.3 4.0 V
Vio_cbus Voltage on CAN pins -40 40 V
gmax Shock Environment in 1ms** -2000 2000 g

** Extracted from IMU max shock.

Physical Characteristics

Description Value Unit

(1)
Mass < 54 g
Size 89 x 92 x 11.6 mm

(1)
Including all connectors and components from
the Complete System configuration.

Environment Testing
OBC’s hardware has been tested under vacuum, thermal and vibration environments, at one of
the IEEC laboratories. Nominal operation was achieved in simulated environments of a typical
CubeSat LEO mission. For more information, please contact IEEC.

17
C3SatP System: OBC

Hardware Layout, Connectors and Pinouts

1. PCB Layout
The following images and blueprints correspond to the OBC PCB version 1.0. The colors of the
frames around connectors represent the subsystem where they are mapped (please see the list
hereunder). Connectors with double frames are used by both OBC MCU and OBDH MPSoC. For
more information regarding OBDH and SDR connectors please refer to their datasheets (ref TBD)
and the C3SatP Complete System Datasheet (ref TBD), as in this OBC stand-alone version these
connectors will not be mounted on the board.

● Red: connector mapped to OBC MCU.

● Blue: connector mapped to OBDH MPSoC.
● Yellow: connector mapped to SDR.

1.1 OBC Top

1.2 OBC Bottom

18
C3SatP System: OBC

2. Connectors mapped to STM32

2.1 J1, J2 – RF Transceiver connectors

The RF Tx and Rx connectors are both a 50 Ω Male Edge Mount PCB Jack, from the SMPM
family of Amphenol connectors. Their part number is the 925-126J-51P, and their pinout is defined
hereunder:

Connector Pin Description

J1 1 Tx line from CC1101
J1 2 GND
J2 1 Rx line towards CC1101
J2 2 GND

2.2 J3 – Serial Wire Debug header

The SWD connector is a through hole 2.54 pitch header, from the MTA100 family of TE
connectivity connectors. Its part number is the 640456-6, and it is compatible with NUCLEO-64
CN4 Debugger, but without SWRST and SWO signals, as can be seen hereunder, in its pinout
definition:

Pin Description
1 VDD (1.8V)
2 SWCLK
3 GND
4 SWDIO
5 JTRST
6 TRACESWO

2.3 J4 – SD memory card holder

Compatible with micro-SD format, up to 32 GB storage. The OBDH can also access the SD
card, through J15 daughter board connector.

Pin Description Pin Description

1 DATA2 6 GND
2 DATA3 / CD 7 DATA0
3 CMD 8 DATA1
4 VDD (3.3V) 9 GND (Detect_b)
5 CLK 10 CardDetect (Detect_a)

19
C3SatP System: OBC

2.4 J5 – I²C connector

The I²C connector is a 1.25mm Pitch Header, from the PicoBlade Connector System of Molex
connectors. Its part number is the 53261-0471, and its pinout is defined hereunder:

Pin Description
1 SCL
2 SDA
3 VDD (3.3V)
4 GND
5 GND (Fitting nails)

2.5 J6 – SPI connector

The SPI connector is a 1.25mm Pitch Header, from the PicoBlade Connector System of Molex
connectors. Its part number is the 53261-0671, and its pinout is defined hereunder:

Pin Description
1 MISO
2 MOSI
3 CS_0
4 GND
5 SCLK
6 CS_1
7 GND (Fitting nails)

2.6 J7 – Power connector

The Power connector is a 1.50mm pitch female header, from the Pico-Lock Connector System
of Molex connectors. Its part number is the 504050-0691, and its pinout is defined hereunder:

Pin Description
1 VDD (5V)
2 VDD (5V)
3 VDD (5V)
4 GND
5 GND
6 GND
7 GND (Fitting nails)

20
C3SatP System: OBC

2.7 J8 – CAN connector

The CAN connector is a 1.25mm Pitch Header, from the PicoBlade Connector System of Molex
connectors. Its part number is the 53261-0471, and its pinout is defined hereunder:

Pin Description
1 GND
2 CAN_High
3 CAN_Low
4 VDD (5V)
5 GND (Fitting nails)

2.8 JX(TBD) – UART connector

The UART connector is a 1.25mm Pitch Header, from the PicoBlade Connector System of Molex
connectors. Its part number is the 53261-0471, and its preliminary pinout (still TBD) is defined
hereunder:

Pin Description
1 GND
2 NC
3 Rx (MCU receiver)
4 Tx (MCU transmiter)
5 GND (Fitting nails)

21
C3SatP System: OBC

Software Development
The software for the OBC will be available under several distribution packages, listed and
explained hereunder. Users can select which distribution to use in the Ordering Form, which can

Bronze
Pre-Installed firmware with core and automatic OBC Software ready to use with custom
configuration in terms of payload communication. This is the default package distributed with the
OBC electronics.

Silver
Pre-Installed firmware with core and automatic OBC Software ready to use with custom
configuration in terms of payload communication and optionally adding new basic functionality
(payload related) using embedded scripting (μPython).

Gold
Precompiled library with core and automatic OBC Software ready to use with an API to use and
customize the behavior, and a build framework to generate new firmwares adding new
functionality to the core.

Platinum
Full Source Code + support.

Next table summarizes the features enabled in each available distribution.

Feature Bronze Silver Gold Platinum

Debug Shell ✓ ✓ ✓ ✓
FreeRTOS ✓ ✓ ✓ ✓
Parameter System ✓ ✓ ✓ ✓
File Transfer Protocol ✓ ✓ ✓ ✓
CCSDS/PUS ✓ ✓ ✓ ✓
User Manual ✓ ✓ ✓ ✓
Build Manual X X ✓ ✓
uPython X ✓ ✓ ✓
CSP X X ✓ ✓
STM32 Debug Enabled X X ✓ ✓
Development Framework X X ✓ ✓
Source Code X X X ✓

22
C3SatP System: OBC

Mechanical Drawings
All dimensions are in mm.

23
C3SatP System: OBC

References

[1] MCU Datasheet: https://www.st.com/resource/en/datasheet/stm32f446re.pdf

[2] CAN transceiver datasheet: https://www.infineon.com/dgdl/Infineon-TLE7251V-DS-

v01_10-EN.pdf?fileId=5546d46259d9a4bf015a3ce40f525e4f

[3] IMU datasheet: https://cdn-

shop.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf

[4] RF Transceiver datasheet: http://www.ti.com/lit/ds/swrs061i/swrs061i.pdf

[5] PMIC datasheet:

https://www.infineon.com/dgdl/Infineon-IRPS5401M-DS-v01_00-
EN.pdf?fileId=5546d4625cc9456a015cd69d402139db

24
C3SatP System: OBC

Ordering Form

Marc with an X
Bronze
Software Silver
distribution Gold
Platinum

CAN Termination R value(1) Ω

Yes
Include Pull-up Resistors?
No
Pull-up R value(2) Ω
I2C
1.8
VDDio Voltage 3.3
5
1.8
SPI VDDio Voltage 3.3
5
1.8
UART VDDio Voltage 3.3
5

(1) Leave blanc for the default resistor of 120 Ω

(2) Leave blanc for the default resistor of 4.7 kΩ

25