Space systems — Cube satellite (CubeSat) interface

This document describes internal and external interfaces of CubeSat. The internal interface includes the interface between components and the interface between a CubeSat platform and a mission payload. The external interface is limited to the umbilical connectors, i.e. access port. The document also describes the items to be included in the datasheet of the CubeSat components and platforms. The datasheet requirements apply to catalogued commercial products ready for sale. This document does not cover the interface between CubeSat and its deployer, i.e. POD. This document is applicable to CubeSats of all sizes.

Systèmes spatiaux — Interface de satellite cubique (CubeSat)

General Information

Status
Published
Publication Date
30-Sep-2024
Current Stage
6060 - International Standard published
Start Date
01-Oct-2024
Due Date
26-Aug-2025
Completion Date
01-Oct-2024
Ref Project
Standard
ISO 17981:2024 - Space systems — Cube satellite (CubeSat) interface Released:1. 10. 2024
English language
34 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


International
Standard
ISO 17981
First edition
Space systems — Cube satellite
2024-10
(CubeSat) interface
Systèmes spatiaux — Interface de satellite cubique (CubeSat)
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Internal interface requirements . . 3
5.1 Unit to unit interface .3
5.1.1 General .3
5.1.2 PC-104 style .3
5.1.3 Backplane style .6
5.2 Mission payload to platform interface .6
5.2.1 Mechanical connection .6
5.2.2 Connection methods .6
5.2.3 Ground lines.6
5.2.4 Power .6
5.2.5 Analogue data interface .6
5.2.6 Digital data interface .6
5.2.7 Debugging .6
5.2.8 EMC .7
5.2.9 Fault isolation and recovery .7
5.2.10 Harmlessness to other payloads, platform and missions .7
5.2.11 Safety requirements .7
5.2.12 Radiation .7
6 Datasheet requirements for CubeSat units . 7
6.1 General .7
6.2 General requirements .7
6.3 Electrical power system unit .9
6.4 Communication unit .10
6.5 Command and data handling unit .11
6.6 Attitude determination and control unit .11
6.7 Antenna unit .11
7 Datasheet requirements for CubeSat platforms .12
7.1 General . 12
7.2 Mechanical interface . 12
7.3 Electrical interface . 12
7.4 Software information . 12
7.5 Operation-related Information . 12
7.6 Safety information . 13
7.7 Reliability information . 13
7.8 Assembly, integration and testing Information . 13
8 External electrical interface (umbilical) . 14
Annex A (informative) Typical digital data communication for CubeSats .15
Annex B (informative) PC-104 style example . 17
Annex C (informative) Backplane style example .20
Bibliography .34

iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 14, Space systems and operations.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
Introduction
This document provides requirements for internal and external interfaces of CubeSat. There is increasing
demand of CubeSat development and utilization worldwide. CubeSats are often built with emphasis on low
cost and fast delivery. Low cost can be achieved by extensive use of non-space-qualified commercial-off-the-
shelf parts and units. Fast delivery is, however, often difficult to achieve when the interface of different units,
such as printed circuit board (PCB), do not match each other. The incompatibility can cause significant delay
in the satellite project, leading to the loss of business opportunity or academic/technology competition.
There is also increasing trend that a CubeSat platform that contains all the satellite bus functionalities by a
single vendor is combined with a mission payload. A common standard on the interface between the CubeSat
platform and the mission payload broadens the choice for the those who want to do a space mission but do
not want to build a satellite to select the platform depending on their needs. This document makes it easier
for CubeSat vendors to enter the market of CubeSat platforms.
This document aims to shorten the time required to design, develop, assemble, integrate and test CubeSat
by clarifying the interface from the beginning of the satellite project. The document also aims to promote
international trade of CubeSat units/platforms and international collaboration.

v
International Standard ISO 17981:2024(en)
Space systems — Cube satellite (CubeSat) interface
1 Scope
This document describes internal and external interfaces of CubeSat. The internal interface includes the
interface between components and the interface between a CubeSat platform and a mission payload. The
external interface is limited to the umbilical connectors, i.e. access port. The document also describes the
items to be included in the datasheet of the CubeSat components and platforms. The datasheet requirements
apply to catalogued commercial products ready for sale.
This document does not cover the interface between CubeSat and its deployer, i.e. POD.
This document is applicable to CubeSats of all sizes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
CubeSat
picosatellite measuring 100 mm cubic and weighting 1,33 kg or less
[SOURCE: ISO 17770:2017, 3.1, modified — Note 1 to entry has been removed.]
3.2
CubeSat form factor
volume unit measuring 100 mm × 100 mm × 100 mm expressed by “U” to describe the volume of each
CubeSat (3.1)
3.3
1U CubeSat
single Cubesat
satellite measuring 100 mm × 100 mm × 113,5 mm and weighing 1,33 kg or less
Note 1 to entry: For the exact external dimension, see ISO 17770.
3.4
3U CubeSat
triple Cubesat
satellite measuring 100 mm × 100 mm × 340,5 mm and weighing 4,00 kg or less
Note 1 to entry: For the exact external dimension, see ISO 17770.

3.5
PC-104 style
CubeSat (3.1) architecture made of stackable printed circuit boards each of which has a 104-pin connector
Note 1 to entry: PC-104 is originally a specification of embedded computer to define both CubeSat form factors (3.2)
and computer buses. PC-104 board used in CubeSat inherits an approximate size of 90 mm × 90 mm, a stackable 104-
pin connector and four mounting holes at the corners from the original PC-104 specification.
3.6
backplane style
CubeSat (3.1) architecture made of one interface PCB at the bottom that is called backplane and other printed
circuit boards vertically inserted to the backplane
3.7
CubeSat platform
combination of CubeSat (3.1) units to provide all the necessary satellite bus functionality, such as power,
command and data handling, communication, attitude control
3.8
deployer
box that encloses CubeSats (3.1) within a confined volume with a lid at one side that closes the ejection port
during the launch phase
EXAMPLE POD (picosatellite orbital deployer).
[SOURCE: ISO 17770:2017, 3.2, modified — Note 1 to entry has been removed; EXAMPLE has been added.]
4 Abbreviated terms
ADCS attitude determination control system
AGND analogue ground
BPB backplane board
CAD computer aided design
CAN controller area network
COTS Commercial off the shelf
DGND digital ground
ECSS European Cooperation for Space Standardization
EIA Electronic Industries Alliance
EMC electromagnetic compatibility
GND ground
I2C inter-integrated circuit
ISS international space station
I/O input and output
LVDS low voltage differential signalling
PCB printed circuit board
POD picosatellite orbital deployer
SCL serial clock
SDA serial data
SPI serial peripheral interface
TIA Telecommunications Industry Association
TRL technology readiness level
UART universal asynchronous receiver/transmitter
USB Universal Serial Bus
5 Internal interface requirements
5.1 Unit to unit interface
5.1.1 General
The envelope shall have enough clearance or notches between the external panel and the unit so that harness
can go through it. A unit shall not rely on the other units to mechanically fix itself. It shall be fixed by poles
fixed to the satellite structure though the mounting holes or attached directly to the satellite structure.
Connection via harness should be avoided as much as possible. Mating connectors should be available widely
in the market. A tool to safely remove the mating connectors shall be available. Ground lines and pins, or
grounding point shall be clearly marked and shall have the minimum resistance. In-rush current associated
with activation shall be minimized. There should be two or more types of digital communication interfaces
and one or more general purpose digital I/O and one or more analogue I/O. Spacing to the neighbouring
components shall be enough to avoid collision during vibration.
5.1.2 PC-104 style
5.1.2.1 General
An example of PC-104 style is given in Annex B.
5.1.2.2 Envelope and mounting holes
Unit shall conform to the maximum envelope of 95,89 mm × 90,17 mm shown in Figure 1. Some part of the
four sides should be notched to provide harness routing. Each unit shall be equipped with four mounting
holes whose diameter is 3,2 mm or larger. The location of the mounting holes shall be as shown in Figure 1.
No parts shall be mounted within 6,4 mm diameter from the centres of the mounting holes. The height of
104-pin female connectors, such as ESQ-126-38-G-D or compatibles, is 11,05 mm as shown in Figure 2. The
parts height mounted on the top side (the side with the female connector) should not exceed 11 mm. Some
units with tall parts such as ADCS can be necessary to be placed at the top of the stack. If the parts are
mounted at the bottom side, the distance B in Figure 2 shall be extended by using a connector with long
male connector pins, such as ESQ-126-39-G-D or compatibles, and adjusting the spacer length.

Dimensions in millimetres
a
4-DIA3.2 THRU.
Figure 1 — PC-104 style UNIT
Key
1 spacer
Figure 2 — PC-104 style stacking condition

5.1.2.3 Connector
Unit shall have a 104-pin connector. The connector is made of two double 26 pin connectors such as ESQ-126-
38-G-D or compatibles. The exact location with respect to the mounting holes shall be as shown in Figure 1.
5.1.2.4 Ground lines
The pin numbers H2-29, H2-30, H2-31, H2-32 shall be allocated to the ground as shown in Figure 3.
5.1.2.5 Power lines
The pin numbers H2-25 and H2-26 shall be allocated to the regulated power of 5 V. The pin numbers H2-27
and H-28 shall be allocated to the regulated power of 3,3 V, as shown in Figure 3. Other pins may be assigned
to deliver the power if necessary.
5.1.2.6 Analogue lines
Several pins shall be allocated for analogue data lines for sensing and other purposes.
5.1.2.7 Digital lines
2 2
The pin number H1-41 shall be allocated to the I C-SDA. The pin number H1-43 shall be allocated to I C-SCL,
as shown in Figure 3. There is a variety of digital communication protocols used in CubeSat. Some are given
in Annex A.
Figure 3 — PC-104 style pin assignment
5.1.2.8 Others
A proper tool, such as a PC/104 extractor tool, should be used to extract the PC-104 connector to avoid
damaging the connector.
5.1.3 Backplane style
Backplane routing shall be reconfigurable either via redesigning the hardware routing or via software
change. The backplane shall be firmly attached to the satellite body preferably via bolts. Each unit attached
to the backplane shall not use its connector for mechanical fixation. Care should be taken when data lines
are near the regulated power lines on the backplane to avoid any noise coupling.
The direction of the connectors on the backplane shall be marked clearly so that no mistake occurs when a
unit board is inserted to the backplane.
The connection to the external solar panels should be made via connectors to avoid harness. If harness is
used, soldering the cables directly into PCB shall be avoided.
Examples of backplane style are given in Annex C.
5.2 Mission payload to platform interface
5.2.1 Mechanical connection
The mission payload shall be attached firmly to the CubeSat structure via through-holes or other methods.
The connector should not be used to mechanically fix the payload to the satellite structure.
5.2.2 Connection methods
The payload and the platform are connected by:
— direct connection via connectors;
— indirect connection through a back-plane or an interface board; or
— harness.
5.2.3 Ground lines
Adequate ground lines shall be provided between the platform and the mission payload unless there is a
specific need from the payload to have separate grounding.
5.2.4 Power
The platform shall provide stable power to the payload. In-rush current associated with activation of the
mission payload shall not cause any harm to the platform operation.
5.2.5 Analogue data interface
At least one analogue connection between the platform and the mission payload shall be provided for
analogue data transfer in both directions. If the interface is not bidirectional, at least one connection for
each direction shall be provided.
5.2.6 Digital data interface
Two or more types of digital data communication shall be provided between the platform and the mission
payload. Typical digital data communication protocols are listed in Annex A. At least one general purpose
I/O between the platform and the mission payload shall be provided in both directions. If the interface is not
bidirectional, at least one connection for each direction shall be provided.
5.2.7 Debugging
The CubeSat platform shall provide pins or connectors accessible from outside the satellite for monitoring
and debugging of the mission payload software.

5.2.8 EMC
The CubeSat platform and the mission payload shall not cause any harm to each other via electromagnetic
noise radiated or conducted.
5.2.9 Fault isolation and recovery
The CubeSat platform and the mission payload shall be designed so that anomaly or failure at one side does
not affect the other side. The CubeSat platform shall be able to protect itself from over-current to the mission
payload. If the CubeSat platform hosts multiple mission payloads, the platform shall protect each mission
payload from the fault of other mission payloads. The CubeSat platform shall be able to power cycle and/or
reset the mission payload automatically and/or by receiving a command from the ground.
5.2.10 Harmlessness to other payloads, platform and missions
The mission payload shall not cause any harm to other payloads, the CubeSat platform or the missions to
be carried out. Examples are electromagnetic interference, excessive heat dissipation and blocking views of
other payloads by the deployable.
5.2.11 Safety requirements
The CubeSat platform shall meet the safety requirements given by launch providers. If the mission payload
poses a unique hazard, either the mission payload or the CubeSat platform shall be able to control the hazard.
5.2.12 Radiation
Since COTS electronic components are often used in construction, care shall be taken to ensure that the
CubeSat platform has resistance to radiation effects in space, especially in the case of semiconductors. Single
event effects shall also be considered. De-rating principles should also be applied.
6 Datasheet requirements for CubeSat units
6.1 General
The information given in 6.2 to 6.7 shall be provided in the datasheet.
6.2 General requirements
The items listed in Table 1 shall be provided in the public domain datasheet or upon request by the customer.
In addition to the items listed in Table 1, information related to procurement, such as price, delivery time
and export control issues, shall be provided by the unit vendor to the customer upon request for quotation.
Table 1 — Items to be provided in public domain datasheet
Note
Document information
Document number and issue date
Revision number
Revision dates
Summary of revision contents
Mechanical
Mass Unit: kg
Size Unit: mm
a
They can be combined into the pin assignment table.

TTabablele 1 1 ((ccoonnttiinnueuedd))
Indicate the physical configuration and the outline dimension in
Physical configuration
drawing
Mounting hole location Indicate the mounting hole location and quantity in drawing
Describe the type of fastener and the fastener torque with toler-
Fastener information
ance in unit of Nm
Centre of mass location Indicate the location of centre of mass in drawing
Three-dimensional CAD model In a standard format electronic file such as STEP
Vibration (random, sinusoidal if any), shock and quasi-static load
Allowable mechanical environment
(if any) levels
Thermal
Unit: W
Heat dissipation
Describe in each operational mode with tolerance considering
input voltage, current and RF output (if any)
Describe allowable temperature range in non-operational, oper-
Allowable temperature range
ational, and start up
Describe type of temperature sensor, data type (digital or ana-
Temperature sensor type
logue) and data format.
Temperature reference position Describe where the temperature reference position is located
Describe heat reduction strategy by conduction and/or radiation
Thermal path
if any
Electrical
Indicate location of the grounding or bonding point where conti-
Grounding/bonding point
nuity check will be made
Input voltage Unit: V
Describe the condition to turn on the unit, such as specification
Input condition
of the power supply, switches etc.
Unit: W
Power consumption (in-rush, peak, nominal)
Show the waveforms of the in-rush current and the voltage
measured by an oscilloscope
Describe how to detect faults such as latch-up and recover from
Fault detection and recovery
them
Describe fault isolation mechanism not to cause any harm to
Fault isolation
other units when the unit power is shut-off
Pin assignment
Describe the connector type and its commercial product name
Connector specifications
for each connector ID
Describe the connector pin assignment in a table format for each
Pin assignment table
connector. Each connector shall have connector ID.
a
Full name of signal Describe full name of signal
a
Acronym for signal Describe abbreviated name of each signal
Describe the type of signal of each pin (e.g. analogue, digital,
a
Type of signal
pulse)
Describe wire gauge (AWG) if harness is connected to the pin
Wire gauge
inside the unit
Describe the max and the nominal current of pin with an ana-
a
Current
logue signal (including power) assigned
a
Voltage Describe the max and the nominal voltage of each pin
a
Input or output Describe whether each pin is input, output or bi-directional.
Frequency or bit rate Describe frequency or bit rate of the signal, if applicable
a
They can be combined into the pin assignment table.

TTabablele 1 1 ((ccoonnttiinnueuedd))
Hot/Return pairing information Describe pairing hot or return pin number, if applicable
Describe the housekeeping data (e.g. temperature) available and
Onboard housekeeping data availability their pin assignment. A table to convert the signal output to the
real physical value shall be provided.
Describe the digital data interface (e.g. SPI, UART, etc.) available
Data interface specification
and their pin assignment.
It should be noted that analogue ground (AGND) and digital
ground (DGND) are not exactly the same. Analogue ground is
typically grounded to one point of the metallic structure. Digital
Analogue ground or digital ground
ground is the ground of electronics circuit. If the unit differen-
tiate AGND and DGND, the impedance between the two shall be
listed.
Software
If available, describe the specification of the development kit,
Development kit availability e.g. computer platform, programming language, software librar-
ies, etc.
If available, describe the specification of the sample code, e.g.
Sample code availability
computer platform, programming language, etc.
Others
Test results See ISO 19683 for the items listed
See ISO 16290 for TRL definition
Flight heritage or TRL
If flight heritage exists, information about orbit, duration and
launchers
If available, describe the tolerance level of total ionization dose
Radiation hardness (flight or test data), mitigation methods against single event
effects
List of materials If any material of outgas concern is used
[4]
If any parts with concerns, such as the ones listed in Ref, is
List of parts
used
a
They can be combined into the pin assignment table.
6.3 Electrical power system unit
The following items shall be provided in the datasheet in public domain:
— maximum, nominal and minimum available power;
— number of power output channels;
— output voltages;
— power consumption;
— output current limit of each channel;
— over-current protection;
— ISS launch compliance;
— inhibit logics to assure cold launch;
— battery specification including capacity and protection mechanisms;
— ripples in the power lines;
— block diagram showing inhibits to be used for end of life electrical passivation;
— block diagram showing inhibits to be used for safety review (an example is shown in Figure 4).

Figure 4 — Example of EPS block diagram to be used for safety review
6.4 Communication unit
The following items shall be provided in the datasheet in public domain:
— frequency including bandwidth;
— data rates;
— receiver sensitivity;
— transmitter output power;
— data protocol;
— modulation options;
— RF cable interface specification.
6.5 Command and data handling unit
The following items shall be provided in the datasheet in public domain:
— processor specification;
— volatile memory specification;
— non-volatile memory specification;
— code storage specification;
— critical data storage;
— power output specification (if any);
— OS (if any).
6.6 Attitude determination and control unit
The following items shall be provided in the datasheet in public domain:
— control mode;
— estimation mode;
— control loop rate;
— pointing accuracy for ADCS units including pointing actuators;
— maximum torque, rotation speed, and momentum storage for reaction wheel;
— maximum torque and diploe moment for magnetic torquer;
— measurement accuracy, range and resolution for sensors;
— exclusive angle, update rate and slew rate for star tracker;
— field of view and update rate for sun sensor;
— field of view for Earth sensor;
— orthogonality, update rate, noise density for magnetometer;
6.7 Antenna unit
The following items shall be provided in the datasheet in public domain.
— maximum number of deployment test allowable;
— non-preferred positions to mount on the satellite body, if any, for the case of a patch antenna due to
EMC issues.
7 Datasheet requirements for CubeSat platforms
7.1 General
The information given in 7.2 to 7.8 shall be provided in the datasheet either in public domain except the ones
in 7.8. Information related to procurement, such as price, delivery time and export control issues, shall be
provided by the platform vendor to the customer upon request for quotation.
7.2 Mechanical interface
The following items shall be provided in the datasheet.
— 3D CAD file in a standard format, such as STEP;
— available payload volume and mass;
— volume and mass of the platform;
— physical configuration and outline dimension in drawing;
— payload mounting method.
7.3 Electrical interface
The following items shall be provided in the datasheet:
— umbilical connector specification;
— connector specification;
— connector assignment;
— data transfer speed from the mission payload to the platform.
7.4 Software information
The following items shall be provided in the datasheet:
— software development environment;
— availability of source codes; if available, description of source code programming language;
— availability of ground station operation source code; if available, description of source code programming
language.
7.5 Operation-related Information
The following items shall be provided in the datasheet:
— maximum, nominal and minimum available power to the payload;
— power consumption by platform during each operation mode (e.g. data downlink, sun-tracking, nadir
pointing);
— nominal supply voltage to the payload;
— maximum supply current to the payload;
— over-current protection threshold;
— battery capacity;
— thermal dissipation method from the payload to the platform;
— thermal control methods of the platform itself;
— data storage capacity allocated for the mission data;
— ADCS sensing and pointing accuracy and control modes;
— ADCS stability;
— software in-orbit reconfigurability;
— satellite position and time stamp;
— housekeeping data;
— uplink specification including frequency, bandwidth, modulation, speed, data format;
— downlink specification including frequency, bandwidth, modulation, speed, data format;
— antenna specification including the antenna pattern and the maximum gain;
— ground station specification including antenna and radio equipment;
— fault detection isolation and recovery mechanisms.
7.6 Safety information
The following items shall be provided in the datasheet:
— initial sequences after deployment from a CubeSat deployer;
— inhibit logics to assure cold launch;
— battery specification including capacity and protection mechanisms;
— block diagram showing inhibits to be used for end of life electrical passivation;
— block diagram showing passivation circuits of pressured vessel if any;
— EPS block diagram for safety review as shown in Figure 3.
7.7 Reliability information
The following items shall be provided in the datasheet:
— table of TRLs (see ISO 16290) for all subsystems;
— flight heritage including orbit, duration, launchers;
— uplink command validation;
— single event effects protection mechanism;
— satellite reset;
— test results (see ISO 19683).
7.8 Assembly, integration and testing Information
The following items shall be provided as documents:
— satellite assembly procedure;

— functional test procedure;
— deployment test procedure if the platform has any deployable, such as antenna or solar panel;
— mechanical test procedure;
— thermal test procedure;
— end-to-end mission simulation test procedure (see ISO 19683:2017, 8.30);
— battery charging procedure.
8 External electrical interface (umbilical)
The following items shall be included in the umbilical connector, i.e. access port:
— flight pins;
— software debug and programming; the debugging includes communication (monitoring, commanding,
etc.) with the flight computer;
— battery charging; the battery’s positive and negative pins should be separated at least by one pin, which
is either removed or connected to the ground via a high resistance;
— battery status monitor;
— inhibit check.
Annex A
(informative)
Typical digital data communication for CubeSats
A.1 General
This annex gives a brief overview of typical digital communication used for CubeSats. The technical detail of
[5]
each serial communication should be found in various textbooks and handbooks .
A.2 I2C
I2C is used typically for communication between a micro-controller and peripheral devices. Most of micro-
controllers and peripherals for embedded system already has built-in I2C ports. The communication is based
on leader/follower arrangement. The leader device controls the communication. There can be multiple
followers (such as sensors) to one leader (such as a micro-controller). The communication uses two lines
(SCL and SDA). The speed is from 100 kbps to 3,4 Mbps.
A.3 SPI
SPI is used typically for communication between a micro-controller and peripheral devices. Most of micro-
controllers and peripherals for embedded system already has built-in SPI ports. The communication is based
on leader/follower arrangement. The leader device controls the communication. There can be multiple
followers (such as sensors) to one leader (such as a micro-controller). The communication uses four lines
(SCLK, MOSI, MISO, CS). The speed is up to several Mbps.
A.4 UART
UART is used typically for communication between a micro-controller and a micro-controller. Most of
micro-controllers for embedded system already has built-in UART ports. The communication is one-to-one
with a pair of Tx and Rx ports. The communication uses two lines for full duplex communication. The speed
is up to 115 kbps. As USB to UART or RS-232 to UART converters are widely available, the micro-controller
programming/debug can be made through UART channel from the external PC.
A.5 CAN
CAN is used typically for communication among multiple micro-controllers and peripheral devices.
Many micro-controllers and peripherals for embedded system already have built-in CAN controllers,
especially the ones for automobile application. CAN provides multi-leader priority-based bus access. All
nodes are connected by two differential wires terminated with 120 Ohm impedance, giving the network
[6]
noise immunity. All nodes are transceivers. The speed is up to 1 Mbps. CAN is defined by ISO 11898-1,
[7]
ISO 11519 and other standards.
A.6 USB
USB is used typically for communication between PC and peripheral devices. The host device can also
provide power to the peripherals. The USB standard is maintained by USB Implementers Forum. Although
USB started as a serial interface for PC, USB devices for embedded systems are now widely available in the
market. USB makes a serial multi-level start topology with the maximum 127 nodes, where one leader host
controller and one follower communicate each other. For versions 1.0 and 2.0, four (Data+, Data-, +DC power,
GND) wires are used. For version 3.0, 10 wires are used.

A.7 SpaceWire
SpaceWire is the physical interconnection media and data communication protocols to enable the reliable
[8]
sending of data at high-speed (between 2 Mb/s and 400 Mb/s) from one unit to another . SpaceWire
[9]
originated from IEEE 1355-1995. SpaceWire is specific to communication among devices onboard
spacecraft. SpaceWire is defined by ECSS-E-ST-50-12C. See Reference [10].
A.8 Ethernet
Ethernet has been widely used for Local Area Networks. It is defined by IEEE 802.3 working group. It can
have multiple speed levels from 10 Mbps to 100 Gbps. Most PCs have an Ethernet port. Data is transferred
via unshielded twisted pair (UTP) cable with RJ-45 connectors if not using an optical fiber cable. Ethernet
also defines OSI layers 2. In the layer 2, Ethernet protocol frame includes 6-byte destination address (MAC
address) and 6-byte source address (MAC address).
A.9 LVDS
LVDS is defined as TIA/EIA-644 and TIA/EIS0-899. It is physical layer interface for high-speed digital
communication (1 Gbps to 3 Gbps). It utilizes differential communication. It is typically used for point-to-
point or multi-drop (M-LVDS) up to 32 receivers high speed communication.
A.10 SpaceFibre
SpaceFibre operates high-speed serial full duplex data links. The SpaceFibre interface expands and
complements the capabilities of the SpaceWire interface, providing data links of higher speed – (up to 20 Gb
per second and higher), as well as protocols for high-performance methods of service quality assurance –
Quality of service (QoS) and Fault detection, isolation, and recovery (FDIR) which are built in the SpaceFibre
interface protocol. See Reference [11] for further details.

Annex B
(informative)
PC-104 style example
PC-104 is originally a specification of embedded computer to define both CubeSat form factors and computer
buses. PC-104 board used in CubeSat inherits an approximate size of 90 mm × 90 mm, a stackable 104-pin
connector and four mounting holes at the corners from the original PC-104 specification.
According to the Internet, a commercial kit of CubeSat existed already in 2003. It was introduced into the
market in September 2003, while the first launch of CubeSat was only three months earlier, June 2003. PC-
104 style was adopted by CubeSat Kit (see Reference [12].). Since then, many commercial vendors selling
CubeSat units used PC-104 style. According to survey done in Reference [13], among 104 CubeSats that had
been launched or were under development by January 2015, 59 % of CubeSats chose PC-104 style.
PC-104 style is made by stacking units. Each unit has 104 pins as shown in Figure 1. An example of satellite
configuration that uses PC-104 style is shown in Figure B.1. The pin assignment of the 104-pin connector
differs depending on the unit vendor. Only the pins specified in Figure 3 are common for most of the vendors.
Figure B.1 — Example of PC-104 style 1U CubeSat
Since the functions of the PC-104 pins differ so much with different implementations, the end result is that
most of the pins are unused and a lot of the advantage of using the stack is lost. Even though there are 104 pins,
an implementation such that on GreenCube, shown i
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...