umsats/cdh-tsat6

Contains software for the Command and Data Handling (CDH) board.

cdh-tsat6's Issues

Satellite Reverse Engineering #2

Reverse Engineer A Satellite Codebase

CDH member @whatdoes3plus1equalsto has found some open-source satellite projects that we could benefit from reverse engineering and analysis of their code bases. There are three parts to this task that I will list here.

1. Reverse engineer the given satellite codebase:
   Take a deep dive into the satellite's codebase. Try to determine what type of code they have written things like "how do they control peripherals?", "Are they using a real-time operating system? If they are what type of tasks do they have and how are they organized" things like that. Also, take extra care to evaluate their error correction code like CRC checks on their memory and other corruption preventative measures.

2. Identify modules that could improve our design:
   Now that you have your footing in the codebase and how it operates, try to identify some useful parts that are missing from our codebase that we could implement in our satellite. Once you find some bring it up with @GrahamDrive or @DaighB and we can discuss how it could be used.

3. Finally some coding!:
   Now that you know what you want to add to the satellite you can try making a test project for a proof of concept. Go ahead and create a brand new project for your dev board and try to implement the given feature you have decided on. Have fun with it play around and add your ideas and flair.

4. Show off your work:
   Now that you have completed the code and tested it you can show it off in a meeting!

University of Patras

This task will be regarding the UPSat CubeSat from the University of Patras in Greece. It is completely open source and good for it uses a stm32 microprocessor, its codebase can be found here. UpSat also has its own Wikipedia page that could have a ton of valuable information you could use the link to it is here.

As always if you have any questions don't hesitate to ask!

Service Telemetry Data

Servicing of Telemetry Data

Problem Statement

Currently, we have no implemented code to deal with servicing our telemetry data. As seen below in the code snippet the telemetry handler task only dequeues a packet from its queue and does nothing with it.
https://github.com/UMSATS/cdh-tsat6/blob/8382f809585326065f5d2c2a5a95bf2da242647b/cdh-tsat6-stm32project-boardV1/Core/Src/main.c#L1173-L1188

Desired Function

We want this task to be able to take the telemetry data and store it in our external memory. This would most likely be done by writing a handler script that would take the data and use the given memory device driver to store the information in a section of memory.

Suggested Start

I recommend familiarizing yourself with the memory drivers for both the Flash and MRAM devices. We most likely won't be using both to store the telemetry data but it would be good to know how both function.

A memory map may also be useful to determine where you want to store certain data, for now we can almost throw it anywhere just to test it, but when we are developing the full memory map @DaighB and @GrahamDrive will assist with sectioning off an address space for the data.

Radio Driver Wrapper

Radio Driver Wrapper

Problem statement

The current radio drivers are basic and not designed for an RTOS.
We need to develop a wrapper for the radio driver to facilitate its integration with FreeRTOS.

To achieve this, we will need to conduct research and development to determine the best method for integrating the radio with various RTOS tasks.

Desired Operation

The radio should operate independently of any specific task, ensuring the radio code is non-blocking. This is crucial because the radio involves extended waiting periods, and we want to avoid CPU hogging during high communication traffic.

Possible Solution

One possible approach is to create a set of RTOS tasks dedicated to managing the radio resource. In this method, any task that wants to send data over the radio will enqueue its information, which will then be transmitted by the radio task.

Error Correction Code (ECC)

Issue 1: Using the STM32L496RGT6 Error Correcting Code module

Overview: The STM32L496RGT6 has an Error Correcting code feature that can detect anomalies within flash memory and run an exception routine when detected. The goal of this task is to research this feature and if possible create a working demonstration of an example project using it.

Note: It may be difficult to write or test this feature as simulating a fault in the code can be difficult to produce.

Internal Chip Temp Sensor

Issue 1: Determining CPU Temperature

Possible Solution: The STM32L496RGT6 has an internal semiconductor-based temperature probe. We could find out how to access and retrieve this temperature information.

Note: This may require the use of an ADC to poll the internal sensor and convert it into a Celsius measurement.

Recommendations: You most likely will need to use an analog-to-digital converter (ADC) to convert the raw voltage coming out of the sensor into a digital value. This digital value can be converted into a Celsius value based on the given characteristics of the internal temperature sensor.

Satellite Reverse Engineering #1

Reverse Engineer A Satellite Codebase

CDH member @whatdoes3plus1equalsto has found some open-source satellite projects that we could benefit from reverse engineering and analysis of their code bases. There are three parts to this task that I will list here.

1. Reverse engineer the given satellite codebase:
   Take a deep dive into the satellite's codebase. Try to determine what type of code they have written things like "how do they control peripherals?", "Are they using a real-time operating system? If they are what type of tasks do they have and how are they organized" things like that. Also, take extra care to evaluate their error correction code like CRC checks on their memory and other corruption preventative measures.

2. Identify modules that could improve our design:
   Now that you have your footing in the codebase and how it operates, try to identify some useful parts that are missing from our codebase that we could implement in our satellite. Once you find some bring it up with @GrahamDrive or @DaighB and we can discuss how it could be used.

3. Finally some coding!:
   Now that you know what you want to add to the satellite you can try making a test project for a proof of concept. Go ahead and create a brand new project for your dev board and try to implement the given feature you have decided on. Have fun with it play around and add your ideas and flair.

4. Show off your work:
   Now that you have completed the code and tested it you can show it off in a meeting!

University of Waterloo (UW Orbital)

This task will be regarding the University of Waterloos cube sat "UW Orbital" that won CSDC 2023 alongside UMSATS. The link to their repo can be found here.

As always if you have any questions don't hesitate to ask!

Maintenance Application Code

Background: The satellite’s application code accomplishes the functionality of our flight mission, to fulfill our payload experiment. However, we need additional code beyond this, to ensure that the satellite is able to operate nominally over our mission lifetime. We will define this extra code as “maintenance code”.

Maintenance Code Example: During orbit, a section of the internal flash storage may become corrupted due to radiation. We can run a CRC check to determine if corruption has occurred. CDH will routinely perform this CRC check to evaluate the health of the satellite. The software which implements this routine CRC check is an example of “maintenance code”. This piece of software doesn’t explicitly implement the mission’s payload functionality. However, the code is just as essential, as it helps the satellite operate nominally.

Task:

1. Research cubesat flight software to determine what types of maintenance code our CDH software should implement. I would recommend looking at any open-source flight software of other cubesats, which have successfully launched and made it into orbit. There are likely also articles published online about flight software architecture for cubesats.

2. Document the proposed maintenance code which you think we should implement into our flight software. (Before doing any thorough documentation, feel free to reach out to me to discuss the code, to see if we’ll want to implement it. -Daigh)

3. Create a sample STM32 project for your NUCLEO board, which provides a demo for this maintenance code. Don’t worry about including all of the satellite application code in this project; just a simple program which demonstrates the maintenance code’s functionality is perfect.

4. After we review your sample project, we’ll work together to implement your code into CDH’s flight software.

UHF Driver

Write a driver library for the STM32L4 to interface with the UHF transceiver.