Author: jharrima

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.

 

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.