Service Module Overview

This chapter presents the service module that will be used in Catarina-A1. The aim is to show the positioning of the boards in the 2U CubeSat, as well as the communication and power interfaces related to the satellite’s service module.

General Diagrams

The subsystems of the CubeSat are arranged within the 2U-based physical structure, as illustrated in Fig. 30.

Fig. 30 Subsystems positioning.

Power Diagram

The block diagram depicted in Fig. 31 provides an overview of the satellite’s power distribution system. In particular, several EPS output converters, with the exception of those dedicated to powering the service module subsystems, can be deactivated via EN pins. The OBDH is in charge of this control, activating or deactivating certain subsystems and/or payloads.

It is crucial to emphasize that the bus designated for the antenna module remains active solely during its deployment phase. In addition, the current values presented in the diagram represent the maximum capacity rather than the nominal operating values. Actual operational values depend upon the variable power output of the solar panels and the varying loads experienced during the satellite’s mission.

Fig. 31 Power diagram.

Data Path Diagram

The data path diagram is shown in Fig. 32.

Fig. 32 Data path diagram.

Deployment Sequence

The deployment sequence of the satellite is the routine to be executed just after the launch. The main objective of this operation is to deploy the antennas and prepare the satellite to start its normal operation.

After the satellite is ejected from the deployer, the kill switches enable the electric power and the three core modules to execute the boot sequence (EPS, OBDH and TTC). The EPS module is ready to operate when the boot finishes. The OBDH and the TTC modules wait for a determined period before starting normal execution.

As the OBDH and the TTC have access to the antenna module, both subsystems can control the deployment of the antennas. Following the CDS specifications [39], all CubeSats must wait 30 minutes to deploy the antennas and 45 minutes to transmit any RF signal. This way, the OBDH waits 45 minutes to send the deployment command to the antenna module. As redundancy, the TTC waits 55 minutes to execute the same operation.

Fig. 33 illustrates the deployment sequence of the service modules.

Fig. 33 Flowchart of the deployment sequence.

Beacon Operation

After the beacon microcontroller’s boot sequence, the beacon’s operation starts. The normal operation consists of reading the data from the EPS and the TTC modules, transmitting the valid data (EPS or TTC packet, in this order of priority), waiting 60 seconds, and repeating this sequence. Fig. 34 shows this behavior.

Fig. 34 Flowchart of the normal beacon operation.

OBDH Operation

After the boot sequence of the OBDH microcontroller, the operation of the OBDH starts. The regular operation consists of reading the housekeeping data from the EPS, TTC, payloads, antenna module, and the OBDH (its own housekeeping data), saving the read data on non-volatile memory, and transmitting the housekeeping data of the satellite as a beacon. After that, it waits 60 seconds and checks if a new telecommand was received; if true, it processes the telecommand; if not, it does nothing. After this sequence, these steps start again. Fig. 35 shows this behavior.

Fig. 35 Flowchart of the normal OBDH operation.

Telecommand Processing

Fig. 36 shows the telecommand processing flow.

Fig. 36 Flowchart of telecommand processing.

EPS Operation

The operation of the EPS microcontroller starts shortly after the release of the CubeSat in its orbit by the deployer. In the first 60 minutes, the module operation consists of reading the housekeeping data from its sensors and managing the duty cycles of the MPPT and heaters. When operational, the TTC and OBDH modules send separate periodic requests to the EPS for forwarding the housekeeping data acquired. The TTC receives a simplified version, while the OBDH receives a complete version of the data. Fig. 37 shows this behavior.

Fig. 37 Flowchart of the normal EPS operation.

Interface Datasheet (IDS)

Interface

To electrically connect all the satellite modules, a PC-104 bus standard is being used. This bus is composed of 104 lines disposed by four rows of 26 pins each, with a vertical and horizontal pitch of 2.54 mm.

Using Fig. 38 as reference, all used positions and signals of the PC-104 bus are presented in Table 27. Table 28 describes each signal and the modules connected to them.

Fig. 38 Reference diagram of the PC-104 bus (top view of a generic module).

Table 27 PC-104 bus pinout.

Pin Row	H1 Odd	H1 Even	H2 Odd	H2 Even
1-2
3-4			EDC_EN	EPL_EN
5-6			BE_UART_RX
7-8	RA_GPIO_0	RA_GPIO_1	BE_UART_TX	GPIO_0
9-10	RA_GPIO_2	BE_EN
11-12	RA_RESET	RA_EN	BE_SPI_MOSI	BE_SPI_CLK
13-14			BE_SPI_CS	BE_SPI_MISO
15-16
17-18	EPL_UART_RX/TX	GPIO_6		GPIO_1
19-20	EPL_UART_TX/RX	GPIO_2		GPIO_3
21-22				GPIO_4
23-24
25-26			PL_VCC	PL_VCC
27-28			TTC_VCC	TTC_VCC
29-30	GND	GND	GND	GND
31-32	GND	GND	GND	GND
33-34
35-36	RA_SPI_CLK		ANT_VCC	ANT_VCC
37-38	RA_SPI_MISO
39-40	RA_SPI_MOSI	RA_SPI_CS
41-42	EDC_I2C_SDA			GPIO_5
43-44	EDC_I2C_SCL
45-46	OBDH_VCC	OBDH_VCC	BAT_VCC	BAT_VCC
47-48	PL_VCC	PL_VCC
49-50	RA_VCC	RA_VCC	EPS_I2C_SDA
51-52	BE_VCC	BE_VCC	EPS_I2C_SCL

Table 28 PC-104 bus signal description.

Signal	Pin(s)	Used By	Description
GND	H1-29/30/31/32, H2-29/30/31/32	All	Ground reference
BAT_VCC	H2-45, H2-46	EPS	Battery terminals (+)
ANT_VCC	H2-35, H2-36	EPS, ANT	Antennas power supply (3.3 V)
OBDH_VCC	H1-45, H1-46	EPS, OBDH	OBDH power supply (3.3 V)
TTC_VCC	H2-27, H2-28	EPS, TTC	TTC power supply (3.3 V)
PL_VCC	H1-47/48, H2-25/26	EPS, EDC, ExpLoRa	Payloads power supply (5 V)
RA_VCC	H1-49, H1-50	EPS, TTC	Main radio power supply (5 V)
BE_VCC	H1-51, H1-52	EPS, TTC	Beacon power supply (6 V)
RA_SPI_CLK	H1-35	OBDH, TTC	CLK signal of the main radio SPI bus
RA_SPI_MISO	H1-37	OBDH, TTC	MISO signal of the main radio SPI bus
RA_SPI_MOSI	H1-39	OBDH, TTC	MOSI signal of the main radio SPI bus
RA_SPI_CS	H1-40	OBDH, TTC	CS signal of the main radio SPI bus
EPS_I2C_SDA	H2-49	OBDH, EPS	SDA signal of the EPS I2C bus
EPS_I2C_SCL	H2-51	OBDH, EPS	SCL signal of the EPS I2C bus
BE_UART_RX	H2-5	EPS, TTC	EPS TX, Beacon RX (UART bus)
BE_UART_TX	H2-7	EPS, TTC	EPS RX, Beacon TX (UART bus)
EPL_UART_TX/RX	H1-25	OBDH, ExpLoRa	OBDH TX, ExpLoRa RX (UART bus)
EPL_UART_RX/TX	H1-27	OBDH, ExpLoRa	OBDH RX, ExpLoRa TX (UART bus)
BE_EN	H1-10	EPS, TTC	Beacon radio power enable
RA_EN	H1-12	EPS, OBDH	Main radio power enable
EDC_EN	H2-3	OBDH, EDC	EDC enable signal
EPL_EN	H2-4	OBDH, ExpLoRa	ExpLoRa enable signal
EDC_I2C_SDA	H1-41	OBDH, EDC	SDA signal of the payload I2C bus
EDC_I2C_SCL	H1-43	OBDH, EDC	SCL signal of the payload I2C bus
GPIO_N	H1-20, H2-8/18/20/22/42	OBDH	GPIO pin (not used)

This project’s distribution pattern of pins is a mix of multiple patterns from CubeSat module manufacturers, such as GomSpace, ISIS, and Endurosat. Some pins are positioned to meet specific project requirements, and the adopted pattern may only be partially compatible with some commercial modules.

Beyond the PC-104 bus, some signals are connected directly by wires and cables, such as the control and power pins of the antenna module, the battery charger, and the programming ports.

Form Factor

The form factor follows a similar specification to the PC-104 standard [1]. The connector used for the interface differs by module; the isolation height and presence of a pin or receptacle are defined from the overall stack-up of the subsystems inside the CubeSat 2U structure. The core modules have smoothed edges, and some linear mounting-hole distances differ from the standard in order to fit a CubeSat form factor. The PC-104 form factor used can be seen in Fig. 39.

Fig. 39 PC-104 form factor.

Telecommunication

This section describes the configuration and behavior of the telecommunication subsystems of the satellite. There are three types of links available in the CubeSat: beacon, downlink, and uplink. The beacon link is a periodic transmission of packets with basic telemetry data of the satellite (containing data from the EPS or TTC subsystems). The downlink is used to receive all data from the satellite, including the results of all experiments, telemetry data, and telecommand feedback. Moreover, the uplink sends telecommands from a ground station to the satellite.

The payload of all packets follows the same structure, with an ID number, the source address (callsign), and the packet’s content (variable according to each type of packet). Following the NGHam protocol characteristics, the maximum packet length, including the ID and the source address, is 220 bytes. Fig. 40 illustrates this packet structure.

Fig. 40 Payload structure of the Catarina-A1 packets.

Table 29 summarizes all types of packets transmitted or received by the satellite, with the ID number, structure and length, and access type of each packet.

Table 29 Telecommunication packets and their content.

Link	Packet Name	ID	Source Callsign	Data (up to 220 bytes)	Size / Access
Beacon	EPS data	00h	"" + "PY0EFS"	EPS data	46 / Public
Beacon	TTC data	01h	"" + "PY0EFS"	TTC data	19 / Public
Downlink	General telemetry	20h	"" + "PY0EFS"	OBDH/EPS data	78 / Public
Downlink	Ping answer	21h	"" + "PY0EFS"	Requester callsign	15 / Public
Downlink	Data request answer	22h	"" + "PY0EFS"	Requester callsign + data ID + timestamp + data	20 to 220 / Public
Downlink	Message broadcast	23h	"" + "PY0EFS"	Requester + destination callsign + message	22 to 60 / Public
Downlink	Payload data	24h	"" + "PY0EFS"	Payload ID + payload data	9 to 220 / Public
Downlink	TC feedback	25h	"" + "PY0EFS"	Requester callsign + TC packet ID + timestamp	20 / Public
Downlink	Parameter value	26h	"" + "PY0EFS"	Requester callsign + subsystem ID + parameter ID + parameter value	21 / Public
Uplink	Ping request	40h	Any callsign	None	8 / Public
Uplink	Data request	41h	Any callsign	Data ID + start timestamp + end timestamp + hash	37 / Private
Uplink	Broadcast message	42h	Any callsign	Destination callsign + message	15 to 53 / Public
Uplink	Enter hibernation	43h	Any callsign	Hibernation in hours + hash	30 / Private
Uplink	Leave hibernation	44h	Any callsign	Hash	28 / Private
Uplink	Activate module	45h	Any callsign	Module ID + hash	29 / Private
Uplink	Deactivate module	46h	Any callsign	Module ID + hash	29 / Private
Uplink	Activate payload	47h	Any callsign	Payload ID + hash	29 / Private
Uplink	Deactivate payload	48h	Any callsign	Payload ID + hash	29 / Private
Uplink	Erase memory	49h	Any callsign	Hash	28 / Private
Uplink	Force reset	4Ah	Any callsign	Hash	28 / Private
Uplink	Get payload data	4Bh	Any callsign	Payload ID + arguments + hash	41 / Private
Uplink	Set parameter	4Ch	Any callsign	Subsystem ID + parameter ID + parameter value + hash	34 / Private
Uplink	Get parameter	4Dh	Any callsign	Subsystem ID + parameter ID + hash	30 / Private

The IDs of the subsystems, modules, and payloads are available in Table 30.

Table 30 IDs of the satellite.

Type	ID Number	Description
Subsystem	0	OBDH
Subsystem	1	TTC 1
Subsystem	2	TTC 2
Subsystem	3	EPS
Module	1	Battery heater
Module	2	Beacon
Module	3	Periodic telemetry
Payload	1	EDC
Payload	2	ExpLoRa

Authentication

All telecommands classified as private use an HMAC authentication scheme. Every type of private telecommand has a unique 16-digit ASCII character key that, together with the telecommand sequence (or message), generates a 160-bit (20-byte) hash sequence to be transmitted with the packet payload. The hash algorithm used is SHA-1. Fig. 41 illustrates this authentication method.

Fig. 41 Diagram of the used HMAC scheme.

Operation Licenses

Regarding non-amateur radio frequencies, Resolution 685, of October 9, 2017, from ANATEL establishes the following.

Art. 9. Assign to the Private Limited Service (SLP), for use by systems for capturing and transmitting scientific data related to space operation, on a secondary basis, the following sub-ranges related to this project:

• 400.15 to 401 MHz;

• 401 to 403 MHz;

• 468 to 469 MHz.

Art. 17. The allocation of all radio frequency bands dealt with in this Resolution follows the restrictions imposed by the respective allocation.

Single paragraph. Those interested in the use of the radio frequency bands object of this Resolution must provide in their projects, until specific regulations are issued on the conditions of use of these bands, criteria for harmonious coexistence with the existing systems in these bands, maintaining specific coordination, when necessary, so that incoming systems do not cause harmful interference to existing systems.