E2 - CubeSat Communications

Electronics and Eco-design

UKSA Space Cluster Microcredentials

02

Module 2-Cubesat Communications

1. CubeSat Communication Requirements.Investigate constraints around data transfer with orbiting satellites. 2. CubeSat Comms Device Architecture and Interfaces.Gain an understanding of typical RF hardware for CubeSat. 3. Investigate COTS Communication Products.Explore example products available for CubeSat Communication.

learning objectives

For any CubeSat (or satellite) operation there will be a requirement for information to gathered and sent back to the operator in order for the mission to be useful. For example, if a satellite is to be used to monitor weather patterns the data collected has to be sent back to earth operations in order for it to be interpreted and used. This is true of the simplest technology demonstrators through to the most complex of deep space missions. Information collected by the satellite and sent back to earth is known as the ‘Down Link’.

CubeSat Communication Requirements

As well as receiving data from the satellite it is often (but not always) the case that command and control information will need to be sent from earth to the vehicle. This path can be used to provide software updates/fixes and control mission objectives. Transmitting information to the satellite is carried out over the ‘Up Link’.

CubeSat Communication RequirementS...Continued

As with your internet connection, it is likely that more download (down link) bandwidth will be required than upload (up link). With the aforementioned weather monitoring use-case only a small amount of data might need to be transmitted to update the CubeSat focal position but a much larger amount required to gather the information from hours of science monitoring and satellite ‘House Keeping’.

CubeSat Communication Requirements...Continued

Space Craft Orbits Coverage area Line-of-sight distance Elevation angle

There are two types of Satellite communication systems in use: Radio Frequency (RF) and Free Space Optical (FSO) also known as ‘lasercomm’. However, for low cost, simple implementation CubeSat typically focuses on RF. There are any number of Comms requirements for CubeSat missions. These should be specified at the beginning of the project. Requirements include but are not limited to:

CubeSat Communication Requirements

Security/Anti-Jamming COMSEC (Security/Encryption) Transmission Method (Spread Spectrum – Frequency Hopping) RFI

Performance Criteria Data Rate End-to-End Delay Link availability Security Standardisation

Architecture Choice Single ground station to space craft Linked Ground station to space craft

And may also include...

CubeSat Communication Requirements

Physical ConstraintsAntenna Size Transmit Power Cost Chanel constraints (air, wire, fibre, space)

It is important to mention the effect of Doppler Shift when discussing RF communications for satellite. Doppler Shift can be defined as “the change in the wavelength or frequency of the waves with respect to the observer who is in motion relative to the wave source” (* https://byjus.com/physics/doppler-shift). Put simply this means that as a satellite approaches and then passes a ground station signal frequency will vary around the broadcast frequency. This applies to both Satellite-to-Ground and Ground-to-Satellite transmission.

CubeSat Communication - Doppler shift

+ INFO

Calculations can be complex to predict the frequency bands for any given satellite pass but can be alleviated by using Software Defined Radio Systems (to focus transmission frequency) and sufficiently wide bandpass on reception. Further investigate Doppler Shift on space communication here:

CubeSat Communication - Doppler shift...Continued

A key aspect in the low cost, COTS based CubeSat ecosystem is to provide access to standardised solutions for complex tasks. Communications protocols are one such area in which standardisation is implemented. Packet based communications protocols standardise the format in which raw data is transferred to or from the satellite to ground station. Data is formed into packets which provide information such as:Call sign (address) of the transmitter (satellite) Destination (address). Timestamp (to allow out of order transmission) Error Protection/Correction.

CubeSat Communication - Standardisation

CCSDS

AX.25

AX.25

CCSDS

The use of such standardisation allows differing satellites to communicate with differing ground stations (as long as they can all interpret the standard). COTS hardware/software which implements these standards reduces cost to the developer. Two communication standards are commonly used in Cubesat development AX.25 and CCSDS. Use the following links to further investigate these two protocols.

CubeSat Communication - Standardisation...Continued

+ INFO

The CubeSat modular architecture provides a perfect environment for COTS based development and as such there are many differing CubeSat Communication platform available. Investigating a typical platform will provide insight to the standard layouts and interfaces. Using the following datasheet extracts, let’s look through the specifications for a typical S-Band Transmitter

Cubesat Comms Device Architecture and Interfaces

+ INFO

For any uplink communication the comms module requires to manipulate the signal received from the RF frontend (OSI Model Physical Layer), strip payload using the associated Data and Link layer protocol(s) to pass for upper layer processing by the OBC. This of course must also occur in the opposite direction for downlink.

Cubesat Comms Device Architecture and Interfaces ...Continued

A typical RF COTS system implements a hardware and software solution which consists of: RF Front End (Antenna Interface) Control MCU (can be split into RF System on Chip and Supervisor MCU) Bus Interface (I2C, SPI, CAN Bus, RS) Power Management The ISIS device hardware layout follows this convention. Hover over the image to provide further detail.

Cubesat Comms Device Architecture and Interfaces ...Continued

A typical RF COTS system implements a hardware and software solution which consists of: RF Front End (Antenna Interface) Control MCU (can be split into RF System on Chip and Supervisor MCU) Bus Interface (I2C, SPI, CAN Bus, RS) Power Management The ISIS device hardware layout follows this convention. Hover over the image to provide further detail.

Cubesat Comms Device Architecture and Interfaces ...Continued

A typical RF COTS system implements a hardware and software solution which consists of: RF Front End (Antenna Interface) Control MCU (can be split into RF System on Chip and Supervisor MCU) Bus Interface (I2C, SPI, CAN Bus, RS) Power Management The ISIS device hardware layout follows this convention. Hover over the image to provide further detail.

Cubesat Comms Device Architecture and Interfaces ...Continued

A typical RF COTS system implements a hardware and software solution which consists of: RF Front End (Antenna Interface) Control MCU (can be split into RF System on Chip and Supervisor MCU) Bus Interface (I2C, SPI, CAN Bus, RS) Power Management The ISIS device hardware layout follows this convention. Hover over the image to provide further detail.

Cubesat Comms Device Architecture and Interfaces ...Continued

Investigation 1

Investigation 2

Use the following websites and/or your own resources to investigate examples of CubeSat Communications COTS Devices. Once complete answer the following questions on CubeSat Communication's Architecture.

Investigate COTS CubeSats Comms Interfaces

Please continue to the next section of the course.

Press back on your browser to exit

THANK YOU!

The RF Frontend implements the interface to the antenna(e). Often antenna are purchased in a COTS arrangement from the same manufacturer so that the two systems have been designed to work to together. However, you’ll notice that this particular layout also supports an ‘Optional RF output’ allowing for designers to implement other RF monitoring hardware if required. Within these types of smaller Cubesat design it is common for a low-gain, omni-directional antenna with ground station using more expensive directional antenna.

Two interface technologies are provided to the OBC/System Bus: I2C (Inter-Integrated Chip) provides a synchronous, multi-master/slave communication bus protocol. I2C is found as standard on the majority of embedded MCUs and MPUs. LVDS (Low-Voltage Differential Signalling) although not as common as a standard interface on MCU/MPU provides strong error protection by design making it useful within space applications. The selected interface will place the received RF payload data onto the system bus or receive the science data ready encapsulate and transmit onto the RF PHY.

A multi-rail PS is likely to be used (here 3V3 and 5V) which will need to be closely monitored for anomalies which could cause system fails. In many cases devices within the Comm module will require strict start up conditions as seen here. These conditions will can be controlled and monitored by ASIC.

The SoC (System on Chip) device provides the necessary hardware to implement encapsulation and de-encapsultation and interface with the RF chain hardware. This particular controller is implemented on FPGA with ARM Controller. This provides a low cost, flexible solution on a general FPGA which has been designed with operational security in mind.