The Main Program Loop (MPL) is the code that is executed when the OBDH system is powered on, and continues to execute throughout the function of the satellite, whenever it is not performing some other tasks. The loop itself invokes different code on each pass, depending on which a state variable telling it what mode the satellite is in. The modes are:
Recovery: The mode after a power on, and the one which the MPL defaults to if the state variable becomes too corrupted (see below)
Idle: The satellite enters this mode after it has been contact from the ground, and whilst in it simply listens for further instructions
Operation: The satellite performs a number of actions at regular intervals (determined by an action list, editable from the ground)
Autonomous: In the event of being unable to contact the ground for some time, the satellite enters this mode, attempting to complete its mission without human control, and blindly transmitting its results.
The state variable
The MPL stores its current mode in a state variable.
Mode | Value (Hex) |
---|---|
Recovery | 0x0009 |
Idle | 0x338E |
Operation | 0x3FF8 |
Autonomous | 0xC00B |
These seemingly arbitrary values are in fact masks; each of the 14 least significant bits corresponds to one of the 14 commands the satellite understands. If the bit is set for a particular mode, the command is permitted in that mode. This prevents scrambled communications or human error from causing an inappropriate command for the satellites mode being executed.
The 14 commands are:
Command name | Hex value | Description |
---|---|---|
CMD_IDLE | 0x0001 | Enter Idle mode |
CMD_RESET | 0x0002 | Enter Recovery mode |
CMD_WAKE | 0x0004 | Enter Operation mode |
CMD_STATUS | 0x0008 | Transmit status to ground segment |
CMD_ACTION | 0x0010 | Insert an action into the action table |
CMD_TABLE | 0x0020 | Transmit current action table to ground segment |
CMD_DELAY | 0x0040 | Insert an action into the action table after a specified delay |
CMD_DOWNLOAD | 0x0080 | Transmit a specified block of data from the SD card to the ground segment |
CMD_LOG | 0x0100 | Returns a pointer to the current log entry on the SD card |
CMD_PHOTO | 0x0200 | Returns a pointer to the current photo on the SD card |
CMD_PAYCMD | 0x0400 | Pass a command to the payload subsystem |
CMD_PAYSTAT | 0x0800 | Transmit a specified input from the payload |
CMD_UPLOAD | 0x1000 | Upload the following data to the reserved block of the SD card |
CMD_REFLASH | 0x2000 | Reflash the OBDH board with the contents of the reserved block |
By performing a bitwise AND operation between a command and a mode, you can see which commands are permitted when.
Fault Tolerance
The integrity of the state variable is incredibly important to the mission, therefor it must be preserved if possible during any single-event upset that might alter its value in memory. If an irrecoverable, invalid mode state is found, the satellite defaults to recovery mode and waits for further contact.
The four valid state values are placed apart from each other in a much larger state space (65,536 possible values). The purpose of this, is that in order for a corruption in the state variable to enter a mode falsely a number of specific bits have to be flipped by separate SEUs.
For example, to be forced from Autonomous (0xC00B) to Recovery (0x0009) mode requires 3 bits to be flipped. If the probability of a single bit of these particular sixteen being flipped is P then the probability of an accidental mode switch can be calculated by multiplying the probability of the three bits being changed:
(1)If the value of P over the time period between ground contacts (when a correct mode can be reinstated) is 1% (a fairly high value) then the probability of an incorrect mode selection is
(2)So we expect to see an incorrect but valid mode state once every million ground segment contacts, for this value of P. In reality, the value is likely to be much lower (this has yet to be formally estimated)
Fault recovery
It is not ideal for the satellite to go into recovery mode for single bit corruptions of its state variable. In these cases, it is usually possible to reconstruct the state variable and continue execution in the correct mode.
Each time through the loop, the state variable is "scrubbed" - a bitwise XOR is performed between each state value and the current value of the state variable, and then the number of '1's in the result counted. If this total is ever equal to 1 for any state value, the loop sets the state variable to that value and continues on.