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).
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
Architecture
The message format and data boxes are joined together to ease readability below.
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.