Software Design

By Jeremy Seiden (Mission, Systems, and Test)

I walk through the software design on the dosimeter/SEU-detection instrument, from data flow block diagrams into packetization and reception at a ground research station.

Table of Contents

Introduction

In the event of actual spaceflight, vast distances separate the satellite collecting the data, and the personnel on the ground analyzing the data and making conclusions. The communication between the ground station and the satellite must be wireless. When considering the environment of space, the communication between the ground station and satellite can be interrupted. Without a packetized format, a loss in the communication link could result in skewed or lost data.

Requirements

Level 2 System Requirement #2: The PCB shall utilize an Atmel 32U4 microprocessor or a Club-approved equivalent to parse packetized data from the sensors.

As can be seen in the italic text above, data packetized data is a critical part of the mission objective. As a result, the process of packing and unpacking the data had to be implemented on the instrument, and on the ground research station (computer/Matlab).

Data Flow

For measurement of events occurring in a space environment, the instruments on the spacecraft collect raw data. Simply, the values collected by the instruments are voltages stimulated by radiation events experienced by the instrument. These values need to be converted, formatted and sent through the downlink back to earth where the data can be analyzed. Below is a data flow chart visualizing the flow of data from the instrument, to the ground research station.

DFlowchart

Packets

As the 2016 SPARCCS instrument project is not utilizing the Arxterra control panel, the data packetization was not taken care of by the arxterra programs. Creating a data packetizing system had to be done from scratch. The first step was to use the ArxBot firmware, and telemetry data information presented by Mission, Systems, & Test division manager to develop an understanding of the packet system.

TELEpack

The above slide briefly describes the basic format of a telemetry packet. For emulation, the most important things to note are the Packet ID and Telemetry ID. The packet ID for telemetry data is 0xCA, this has been carried over directly to our code as this ID is considered universal. The Telemetry ID value is very important, especially with the inclusion of our SEU monitor (uCamII CMOS camera). As the instrument board has two instruments collecting data, identification has to be given to the data packet to distinguish which elements contain relevant instrument data. In a version of our trial code, two different methods were tested.

First, individual data packets were used. This allowed for the separation of data from each instrument. Simply. One packet contained data from one instrument. Below is an example of the packet structures, PackGTD being the data from the Geiger Tube and PackSEU being the data from the Single Event Upset Monitor.

PackGTD[0] = 202;
PackGTD[1] = 2;
PackGTD[2] = 1;
PackGTD[3] = P1;
PackGTD[4] = 255;

PackSEU[0] = 202;
PackSEU[1] = 2;
PackSEU[2] = 2;
PackSEU[3] = P2;
PackSEU[4] = 255;

This made distinguishing and graphing the data easier as the data came in with only one relevant piece of instrument data at a time. However, this severely impacted the efficiency of the communication. To revise and improve the efficiency of the data transfer. The packet was condensed so that one packet contained Data from both instruments. Below is an example of the longer, condensed packet structure where PackD is the data from the instrument.

PackD[0] = 202;
PackD[1] = 4;
PackD[2] = 1;
PackD[3] = GTD;
PackD[4] = 2;
PackD[5] = SEUD;
PackD[6] = 255;

Ground Research Station

Again, with typical spaceflight programs, the analysis of data collected by the space vehicle is conducted here on earth. To emulate this setup, a computer will be used to collect data from the instrument. In this case, the Spring 2016 SPARCCS project will use Matlab to collect, process, and display data from the instrument board via an RS-422 connection.

Conclusion

In the absence of club-provided guidelines for data packet structure, a packet format was created based on information provided by division resources including reference material and arxbot firmware. The packet structure, while basic, allows for the transfer of data from both instruments simultaneously. For future iterations of the SPARCCS project, the packet structure can be easily modified to include more data or follow a different format.

The ground research station code and a larger resolution data flow chart can be found here.