This note discusses how to integrate the payload into the satellite bus, also how we can set up a development environment. (Some figures from the NanoAvionics M6P Software and Hardware ICDs).

CubeSat bus overview

The figure below shows how the M6P CubeSat bus generally is organized. In our case, we do not have the propulsion unit.

Our payload should be connected to the Payload Controller (PC) through the CAN-bus.

Communication network and software architecture

The communication between ground and satellite, as well as between sub-systems is made possible through the use of CubeSat Space Protocol (CSP)

This means that the our payload processor must implement CSP in order to be able to connect and communicate with the rest of the satellite. This also implies the use of CAN-bus interface for all communication. An option might be that payload data (images) might be transmitted over a RS422-interface, as a streaming interface (see below). Refer to M6P/Payload ICS page 10.

Payload integration

The figure below shows conceptually how the payload can be organized and integrated into the satellite bus. The buses are two-way, but for ease, to show the flow of data and messages, they here flow from the payload towards the mission operations. Our data (and commands, telemetry and messages between the payload and ground station, and between the payload and other satellite sub systems will be encapsulated in CSP, as well as the link layer for each data transfer; either CAN or an RF link layer, for example. The DATA-block also implies encapsulation in a message format (our own), and that the ARM-processor in payload has its own set of commands, settings and telemetry data sources, that will be compiled into various messages.

Data encapsulation into messages and frames.

Refer to the M6P Software ICD for more details on how the payload and satellite should be integrated and how the CSP protocol and other system commands work.

Architecture

The message format and data boxes are joined together to ease readability below.

Image AddedImage Removed
Possible architecture for payload design and integration

Development

During early development phases, we might make use of the provided remote flat-sat, that can be used with a communication architecture as depicted below.

Payload development using remote flat sat

Electrical power bus

The Payload Controller provides a set of voltages (refer to M6P/Payload ICD p. 9): 3.3 V, 5 V, 12 V 15 V or unregulated battery voltage, that may be between 6.4 to 8.4 V. Each bus may deliver 3.0 A. We have a choice to either use regulated voltages or use battery voltage and regulate to our own needs on the payload processor board. Regulating regulated voltages should be avoided, due to efficiency loss.