SOURCE

The structural design team is in charge of the physical layout and the thermal management of the satellite. It is this team’s job to fit the components of all subsystems into the given dimensions and to make sure they stay within their operating temperatures. It also designs the deployment mechanisms for the solar panels.

The primary structure functions as the backbone of the satellite and houses all experiments as well as their supply systems. Each printed circuit board is mounted on four threaded rods secured by a clamping mechanism. Afterwards solar panels, antennas and experiments are attached to the outer surface. All electrical components are monitored by thermal sensors and kept in their respective operational thermal range with heaters. FEM and thermal simulations analyse the behaviour of the satellite during launch and on orbit. Currently, the primary structure and ground support equipment are prepared for production. An assembly and integration plan is being prepared as well. After assembly and integration of the prototype shaker tests to simulate the launch loads will be carried out.

Another task of the structural team is the design of the deployment switches. These are released when the satellite is ejected from the CubeSat deployer and then activate the satellite.

The Attitude Control System (ACS) is in charge of the pointing of the satellite. After the ejection out of the rocket it needs to stabilize the satellite. During the main mission the solar panels need to be reliably pointed towards the sun and occasionally the cameras towards the earth. To achieve this and to provide context to payload measurements, a precise determination of the attitude must be possible on board.

SOURCE uses magnetorquers to adjust its attitude. These coils create a magnetic field which aligns itself with Earth's magnetic field. This process introduces a turning moment which can be used to control the satellite. With only magnetorquers it is impossible to create moments around the magnetic field vector. This means that the satellite can only be controlled in two axes at any given time. However, as the satellite flies around the earth it travels through different regions of the magnetic field, allowing for full three-axis control. The magnetorquers on SOURCE are self-built and fully developed by students. Two are designed as cylindrical coils with ferrite cores, the third as a flat square with no core. Prototypes of the design have been successfully tested with excellent performance.

To determine the satellites position and attitude, sun sensors, magnetometers, GPS and gyroscopes are used. The sensors measurements are compared to a sun model and a magnetic field model. As Earth's magnetic field changes depending on the satellites position, the GPS is used to gain accurate position information. All the sensors measurements are combined into a 3-axis attitude determination in a Kalman filter.

Besides these for CubeSats typical sensors the earth observation camera will be tested as a sensor for attitude determination. It will take pictures of the stars which will then be compared to a constellation map. The concept of star trackers has been used on many satellites and is nothing new. However, using a commercial earth observation camera is a novel development. This is a technology demonstration which means that the system as a whole cannot be dependent on the camera as a sensor. If it works it promises much more accurate attitude information than the other sensors can provide.

The sensors, readout and control electronics for the ACS are located on the two housekeeping boards. Prototypes and qualification models of these PCBs are currently being built and tested.

The attitude control software is being developed in a Matlab-Simulink based simulation environment. The control laws for detumbling, sun tracking and camera pointing are all tested and shown to be working, but will need to be further optimised when the satellite design parameters are fully consolidated and the target orbit is fixed. The simulation also includes the sun sensor, guidance and attitude determination algorithms.

The subsystem on-board and data handling is the central unit responsible for controlling and monitoring the CubeSat. Commands are distributed, the status of the entire satellite is monitored and events are logged. The on-board computer used to satisfy the requirements essentially consists of a microcontroller, different memory units and various interfaces for the communication with other subsystems.

The basic tasks which are assigned to the OBDH system are:

• the storage of housekeeping data.
• the storage and processing of payload data.
• the transition between the satellite modes.
• the execution of the attitude control algorithm.
• the detection and correction of device malfunctions.
• the execution of telecommands.
• the preparation of data for the transmission to the ground station.

Hardware:

As on-board computer with sufficient computing power and memory capacity for the reliable execution of all the tasks the iOBC (ISIS On-Board Computer) was selected in Phase A.

• 400 MHz ARM9 processor
• Volatile memory: 32MB SDRAM
• Mass data storage: 2x2GB SD cards
• Code storage: 1MB NOR Flash
• Critical data storage: 256KB FRAM

The "Port Expander" is a circuit board developed by us which sits on the on-board computer. Its jobs are to perform conversion of some signals, route connections relevant to the on-board computer, increase the amount of ports available to us, and connect to the payload on-board computer. In addition, the Port Expander connects the on-board computer to the CubeSat-Kitbus, which is the main bus of the satellite, connecting all circuit boards.

When signals are sent between different components, we use various protocols and connectors. Some of these include RS485, on which we use the unified space data link protocol (which uses "frames" to transport data "packages"), and the serial peripheral interface (SPI). SPI is a very important interface for us, as we connect over 30 devices to the on-board computer using this bus. In addition, we use USB and Gigabit Ethernet adapters to connect the on-board computer to the payload on-board computer via the Port Expander.

Software:

The figure above titled "Software Architecture" shows the fundamental structure of the on-board software for SOURCE. The AT91SAM9G20 as execution platform represents the physical layer in the architecture upon which the real-time operating system FreeRTOS is implemented. For the implementation of FreeRTOS, the microprocessor must only provide a timer that generates an interrupt each millisecond. FreeRTOS allows the separation of a program in several processes by managing the assignment of processor internal resources like processor time and memory to the various processes. In contrast to standard operating systems, a process in a real-time operating system (RTOS) with lower priority can never be executed before a process with higher priority. This is one of the crucial features of an RTOS and a prerequisite for ensuring the real-time requirements of the software.

Furthermore, the software is based on a Flight Software Framework (FSFW) developed at the Institute of Space Systems (IRS) which is already being used successfully for the software of the small satellite Flying Laptop. The FSFW provides several building blocks and templates for software components in the form of abstract classes promising a reduction in development time and an increase in reliability for new flight software. As an example, the FSFW contains a sub‑framework facilitating the programming of PUS services. PUS stands for Packet Utilization Standard and is a protocol developed by ESA. This standard specifies a set of mission‑independent services for satellite operation and defines the associated packet structure resulting in communication compatibility between several ground and on-board systems. For implementing the Software we use the programming language C++.

For software prototyping, the AT91SAM9G20-EK development board is used which is based on the same microprocessor as the iOBC. Currently, the software consists of FreeRTOS, the FSFW and several PUS services programmed during phase C1. Furthermore, the lwIP stack was implemented and the Ethernet interface of the AT91SAM9G20-EK was configured which allows uncomplicated testing of the PUS services. For the testing, a python script was written that automatically sends different telecommands and verifies their processing through the returned data.

In phase C2, the integration of all the device drivers into the software is planned. This includes the programming of the interface drivers as well as implementing device‑specific components such as communication protocols or troubleshooting measures.

The main task of an Electrical Power Supply (EPS) is power generation, energy storage and the distribution of power to other subsystems. It also has to provide power to deploy the solar arrays and activate the satellite. The EPS of SOURCE required some more advanced features and functionalities compared to a normal CubeSat mission. Therefore, the solar array configuration and PCDU (Power Conditioning and Distribution Unit) is self-developed.

A total of 56 solar cells provide up to 32W under ideal conditions, which can be stored in a 75Wh space qualified lithium ion battery from Gomspace (BPX). To maximise the power output of the solar cells, Maximum Power Point Tracking (MPPT) is performed by the PCDU. This is controlled by a radiation hardened microcontroller (Vorago 10820). The microcontroller also controls the switching between the various CubeSat modes (as commanded by the OBC) and the individual power output channels. There are 32 switchable channels which control every subsystem and component of the CubeSat. Additionally, the subsystems power consumption is monitored for over-currents. The health of the OBC is monitored as well and can be rebooted in case of a failure. The PCDU can also be directly commanded via the communication subsystem from the ground with so called High Priority Commands that can reset either the communication subsystem, the OBC or the entire satellite. The EPS is crucial for mission success so redundancy and fail-safe components are implemented as far as possible and a mix of COTS and space qualified components is used.

The communications subsystem has three tasks:

• Receive commands to control the satellite
• Send status information to the ground station
• Transmit payload data

The first two are most critical for the mission, since an erroneous command can easily let the satellite malfunction. Payload data, on the other hand, focuses more on the achievable data rate. Up to 1 Mbit/s is planned.

All data is sent by electromagnetic waves. The direct communication between the IRS ground station and SOURCE is conducted in the S-band (2 – 2.4 GHz). This can also be used to communicate with partner ground stations worldwide. S-band technology is more typical for larger satellites but is now finding its way into CubeSats. Additionally, SOURCE can communicate to commercial satellite constellations in the L-band (1.6 GHz). This allows SOURCE to transmit data regardless of its current position. Such abilities are rare for CubeSats.

The satellite receives signals through two patch antennas. This antenna type can receive from any direction. The signals are then processed by a transceiver, which converts them into computer-readable data. The reverse path, towards the ground station, works exactly the same. This defines the transceiver: it combines a receiver and a transmitter. The currently planned transceiver is supplied by Syrlinks.

All transmitted data is packed into protocols for each layer. Additionally, certain coding algorithms are employed to increase the reliability of the transmission. With these the system can detect and correct errors in any received data. SOURCE uses international standards as defined by the CCSDS. FPGAs provide the computing power to code or decode messages.

The eventual reentry – which will destroy the satellite – may happen over an area without ground stations, for example the Pacific Ocean. To preserve the important atmospheric data that is gathered during this phase, a secondary communications system is installed. It communicates to the commercial Iridium satellite constellation in the L-band (1.6 GHz). Iridium operates a constellation of 66 satellites; primarily for satellite telephones and internet. The transceiver on SOURCE was, originally, meant for regular satellite telephones. Through this network short messages, similar to SMS can be sent.

The Operations and Ground Systems (OPS&GRND) subsystem deals with the planned operation of the satellite and the infrastructure required to operate the ground segment - which is the counterpart to the space segment (the satellite). The ground segment includes the ground station, the Mission Control System, the Mission Planning Tool and the Flight Dynamics Tool.  SOURCE will use the ground station of the IRS, which is currently operating and used for the satellite "Flying Laptop" (more information can be found here).
However, this will require re-engineering the existing interface software  of the ground station so that it can also be used for SOURCE. The mission planning tool is currently being developed and a similar infrastructure as in the other ongoing satellite projects of the institute is used as Mission Control System (MCS). The flight dynamics tool is used to evaluate the navigation data and provides essential data for mission planning, e.g. at what time SOURCE flies over which coordinates. In a further step, the task of this subsystem is to automate as much work as possible in order to simplify the future operation of the satellite.

Furthermore, OPS&GRND deals with the creation of the user manual of the space segment, as well as the creation of the satellite reference database (a kind of dictionary) to translate between satellite and ground segment. In addition, OPS&GRND supports the creation of procedures and their testing, as well as the appropriate adaptation to operational constraints. In preparation for operations, various scenarios must be simulated and a schedule created to ensure safe operation of the satellite and thus the success of the mission. The corresponding training of the initial mission critical Launch and Early Orbit Phase will be performed in close cooperation with the subsystem Testbed.