UTAT Lead Specific Stuff:

1. Go through ‣.
2. Leads Meeting: Saturday at 11:30am.

CDH Lead Specific Stuff:

1. CDH Home Page: Command & Data Handling (CDH)
2. CDH Responsibility:
   • Basically everything above FreeRTOS (Including FreeRTOS) in the Software Hierarchy
   • The system diagram explains the intended functionality of the system. Split into a few basic but separate ideas:
     1. 2 MCUs: Pay-Elec (H7) and OBC (G4)
     2. FreeRTOS Level: Modes
        • The modes determine the overall objective of the system at the current time. When a mode is started, it has a list of tasks to complete, and it will exit the mode once the task is complete.
        • A mode can be one of two types: Follow-through and Passive.
          • Passive: The currently running mode is determined by the priority level of the mode. If Mode 1 is currently running and it is of priority 5, and Mode 2 is initiated, if the priority of Mode 2 is higher than 5, then Mode 2 pauses Mode 1, and begins running. Once Mode 2 exits, Mode 1 resumes running exactly where it stopped. This functionality is handled by FreeRTOS. (Mode 1 and Mode 2 are passive).
          • Follow-Through: The currently running mode is determined by the priority level and the order in which tasks were started. When Mode 3 is started, it takes a semaphore indicating that a Follow-Through tasks has began running. When Mode 4 is started, it attempts to grab the semaphore, and notices it is already gone. It goes to sleep waiting on the semaphore, no matter what the priority level of Mode 3 and 4 are. Once Mode 3 finishes, it gives back the semaphore and exits. Mode 4 then grabs the semaphore and begins execution. This functionality has been implemented using FreeRTOS and a task called ThreadTerminator. (Mode 3 and 4 are follow-through). More about this can be read here:
          • Constraints: The priorities must satisfy this condition: All passive tasks must have a priority lower than ThreadTerminator. All follow-through tasks must have a priority higher than ThreadTerminator.
          • ThreadTerminator: This is needed to ensure that the thread completely finishes execution and exists before the next mode takes its place.
     3. CSP Level: Handlers
        1. The handlers will be individual tasks (as of right now, can be changed if we hit into memory limits when running them all). The handlers interface with peripherals and other tasks, and send and receive information to and from the modes. This is done to ensure that if a handler waits a long time on a reply, it does not block the modes, and allows them to either continue running, or go to sleep waiting on a response. Data handling is done using CSP, which is built on top of FreeRTOS. This allows for a simple way to send information between different tasks, MCUs and some of the peripherals (The ones that support CSP).
     4. SFSF Level: Services
        1. The services are basically the SFSF layers (in Software Hierarchy). SFSF was a framework that we couldn’t get compiled, so we’re recreating its functionality ourselves. Github Link. This services are mostly independent, and will also be running as individual tasks.
           1. The housekeeping and parameter service are used to gather system information and update a global parameter table. This table is used by the Command Service to inform the Command Handler which mode to run, and control the overall behaviour of the system.
     • Currently, we plan on having sender and receiver threads that take care of the data handling between tasks. These can be called by other thread and given the data and an address. If this method is bad, feel free to change it, we haven’t been able to test it yet.
3. CDH Tasks:
   1. The services Cubesat Space Protocol
   2. Getting CSP to work with CAN: CSP + CAN.
   3. Porting the GitHub Projects to the G4: G4 Port
      • CSP and FreeRTOS and all that stuff is set up right now on the H7s. Because we want the same functionality on the G4, we need to make sure that the code works on both. There can be two versions on the GitHub, and it will probably be needed because of the two IOC files.
   4. Data Integrity: I2C Error Detection and Correction
   5. Program Integrity: Watchdog Timer - Internal, Watchdog Timer - External, Watchdog Timer - Software, Safety Mode

Notes

Originally, the CDH lead was given the responsibility to go to mission ops meetings. This was good at the start, when the modes of operations were being created and whatnot. However, now mission ops is more focused on groundstation works. Speak with the mission ops lead and decide whether you’re needed at those meetings.

Important Links:

Electrical System Diagram

Ops Docs — FINCH Operations Plan (WIP)

‣