Welcome to Project Belka!

What we plan to build.

Our goal is to build a standard protocol to maintain data integrity among computing components like UART, I2C, and SPI in space. Because of space’s radiation and other various moon effects, the data that the moon rover receives and collects may be unexpectedly altered and undetected. We plan to have fall-back and foolproof method for this data transfer so that important and expensive data isn’t lost.

Our team is working in conjunction with CubeRover, Carnegie Mellon’s Moon Rover project, to help achieve this goal.

http://cuberover.space

What our design goals are.

Our design goal is to have a modular system in place both for testing and verification. Our goal is to simulate the radiation through the use of a microcontroller, that will both unit test each component and allow for pass-through calling between components. Since energy and power are limited on the rover, we are maintaining low-energy and high-efficiency error detection and error correction. We will provide a seamless User Interface such that anybody should be able to manipulate the radiation simulation based on each protocol that the rover is using.

What’s cool and unique about the project.

Our project is possibly going to the moon- probably the only capstone project that will be going to the moon. Additionally, our project is special and unique because with our project, CubeRover will be able to successfully verify the data that it receives and transmits from the moon; without it, the data that it collects may inaccurate without users knowing. Moreover, the potential effects that moon radiation will have is unpredictable since error detection and handling on the moon is an uncommon issue for most devices. Having to think of every corner case and scenario that might happen before we eventually send our code to space will push us to our limit of how much we can plan ahead.

API Implementation Updates

In the previous posts, we discussed the progress of our API design.  With this design, we have began researching the best ways to implement transactions between the MCU and GUI using either the USB or USART/UART port on the STM32 Microcontroller connected to the computed to display on the GUI.  So far, we have decided that the computer will receive and send data from the MCU connect the via the USART port on the MCU because:

  1. The USART port can send data via bytes serially.  With the current rough draft of our API design, the protocols on each component will be determining what error codes to send to the GUI.  These error codes will be given to the MCU, which will send it to the GUI via the USART port.
  2. The USART port can transmit data via bytes serially; by sending bytes serially, we can enumerate and send control signals to the MCU that will indicate what type of error we would like to simulate.
  3. If we do implement combinations of errors, we could enumerate the combinations of errors into error and control signals, allowing for us to simultaneously test the detecting of multiple errors.

Currently, we are deciding between implementing this in C or microPython.  Using C, it would be less of a learning curve and would be able to integrate better with our programs that we are already writing in C.  However, using microPython would be less difficult given the various built-in libraries and would allow for us to integrate easily with external C programs that we could write if the built-in functions are insufficient.  Furthermore, microPython offers libraries custom to STM32. We feel that deciding whether to use C or microPython will depend on what will integrate best with the remaining aspects of our design that still need to be determined.

To-Do:

  1. Research more into microPython and C implementations of USART and determine which one will fit best with our design.
  2. Determine how the remaining components like the communication between MCU to I2C, SPI etc. will be implemented

 

 

Architecture Rough Draft Overview

We have begun our hierarchical design between the GUI and MCU and between the MCU and each component. This is shown below:

Our GUI is designed such that it serves as our control center on how we would like to manipulate data and we want this manipulation to be real-time. Our desire is to have a clear divide of GUI and MCU through our defined API. The GUI will only be able to send control signals on how data should be manipulated and the MCU should only be able to send status signals on successful recovery/successful protocol calls. We imagine both the GUI and MCU to deal with concurrency with two threads running simultaneously, one for sending and one for receiving data. Our MCU will likely have at least four threads running in addition to handle the cases of each protocol concurrently. The reporting back to the GUI will be in serial transmission, so we’ve decided to place a protocol status buffer within the MCU which will hold the success of each call made.

Our initial API design is here:

Below is an example of how the microcontroller would interact with one of our components:

We have placed the responsibility of packet generation on our microcontroller for now. We’ve decided that this is an simpler framework that allows for easier unit testing of each error correction/detection wrapper protocol. At the end of the project the goal is to remove the microcontroller entirely and still have the protocols working as suspected. The microcontroller will predetermine what the response from the client component should be and add to the protocol status buffer the result of whether the responses matched.

 

A Initial Proposal for Turbo Coding Scheme

Our goal is data integrity without risking the expense of power and energy. The fundamental question becomes how do we achieve this balance between the two factors?

For space exploration we are not dealing with cases where error detection is trivial since it’s still largely unknown of the exact effect. We are anticipating both a high bit error rate (the probability of any bit being an error in transmission) and a high signal to noise ratio (transmission power to noise power). An ideal case for us would be to achieve Shannon’s Limit, the maximum rate of error-free data that can theoretically be transferred over the channel if the link is subject to random data transmission errors, for a particular noise level. Shannon’s limit becoming the driving force for our use-case since we are anticipating high noise signals. Turbo codes are the closest attainable coding to Shannon.

Turbo coding is a mix of both block and convolutional coding, but requires block code. This would suite us well for I2C and UART which have an established data format.

Turbo decoding is cyclical in nature that will continue to iterate until a hard decision is made, initially assigning weights to each value until a condition is met.

More to come.