Conceptual Operations
What pFS should be able to do in-flight conceptually
General Aspects of pFS
The purpose of the 2019-20 TJREVERB mission is to test the usability of Iridium radio in Low Earth Orbit. Since the Iridium radio is not verified to work in LEO, another radio called the APRS radio is used as a control group. All critical messages from the ground station to the satellite are sent through the APRS radio.
Critical Messages include:
Telemetry dumps
Command Execution messages
APRS echos
To test the usability of the Iridium radio, all non critical messages are sent through the Iridium radio.
Non Critical Messages include:
Heartbeat messages
Critical Messages
Telemetry Dumps
On a set interval, the satellite will send a collection of all the data it has collected through APRS
APRS echos
The physical APRS radio sends automatic echo messages to the ground station. This aspect is not controlled by the flight software whatsoever
Command Execution
The TJREVERB groundstation should be able to send a message to the satellite via the APRS radio, containing a message which describes a specific function the flight software should execute.
If the most recent telemetry data is required by the groundstation, the TJREVERB groundstation should be able to send a message via the APRS radio telling the satellite to trigger a telemetry dump regardless of the interval. The flight software should receive such a message through the APRS radio, recognize the message as a command, and follow through with the execution of that command
Non Critical Messages
Heartbeat messages
On a set interval, the satellite will send a basic message(i.e 'I'M ALIVE') through the Iridium radio for the sake of using the iridium radio
Startup
This is how pFS
should behave when flight-pi
boots up for the first time.
When the flight computer(
flight-pi
) first boots, the computer shall run themain.py
file to begin the initialization ofcore
When
core
is initialized, it shall read from theconfig
and initialize allsubmodules
regardless of order. In addition it shall initialize all other required variables.After
core
is initialized,main.py
shall call thestart()
method in core which will begin the startup sequenceIn the startup sequence,
core
shall call thestart()
method for all thesubmodules
listed under ‘A’submodules
. Afterwards,core
shall determine if it is booting up for the first time and sleep for 30 minutes if it is the first boot before initializing ‘B’ and ‘C’submodules
. If it is not the first boot,core
shall ignore the 30 minute sleep periodAfter starting all
submodules
,core
shall iterate through itsprocesses
and start all of itsprocesses
Here is an excerpt of config/config_default.yml
that outlines the startup process for core
:
Command Ingest
It would be helpful to read about message formatting before reading this section
When APRS receives a message from the ground station, it shall send the message to
telemetry
for processingOnce
telemetry
determines the message is of typeCommand
, it shall send send the message tocommand_ingest
Once
command_ingest
encounters the message, it shall parse the message and determine the corresponding function to execute and then execute itOn a successful execution,
command_ingest
shall send a message through APRS that acommand
was executed successfullyOn an unsuccessful execution,
command_ingest
shall send a message through APRS that acommand
was not executed successfully.
Dumps and Heartbeats
On a set interval, the satellite shall send data dumps and heartbeat messages to deliver data to the groundstation.
Telemetry Dump
Every hour, the satellite shall send all telemetry data collected through the aprs
radio. The satellite shall purge the data collected once it has been sent to the groundstation. This dump message is flagged as a Critical Message.
Telemetry Heartbeat
Every hour, the satellite shall send a simple, "I'M ALIVE", message through the iridium
radio. This heartbeat message is flagged as a Non Critical Message.
Modes
ModesLast updated