Author: jharrima

Team Update 3/7/2020

What are the most significant risks that could jeopardize the success of the project?
Most of the problems that we were at risk for last week were successfully solved.
Our new risks come with the learning curve of using our new components that we ordered because there hasn’t been a way to really interact with them if we did not physically have them.
Besides that, we believe that we should be okay. We still need to figure out which addresses to write to and how exactly we will set up the components to interact with each in terms of where they will write data to, read data from, etc.
How are these risks being managed? What contingency plans are ready?

The risks are being managed by having this built into the slack. All pieces of code should be ready to go by the next time we meet with our components, so we can just now focus on the integration aspect of the project.

A contingency plan that would help is to get at least one protocol system working for our protocol wrapping. Then we can slowly start to add more and more tests and then eventually develop the entire system running at once. We believe that we can at least do one system in the next week if we have our components, so that is our goal for this week.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?

There was a change to the system that was a compromise between the decentralized and centralized models. We are also slightly changing the way that we pass data during what we call “debug” mode which sends the corrected data after an ACK. This changes the block diagram.

We also set hard requirements based off of the components that we are using to set our constraints.

Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

This change for the architecture was necessary in order to follow our three phase plan for proof of correctness. Without this change we wouldn’t be able to remove the microcontroller and still show that our system works, but we also needed it so that we can reduce the weight we would put on the laptop that we’re using by keeping the fuzzing of data on the microcontroller still. Packet generation has now been delegated to each individual component due to the more realistic setting instead of placing it onto the fuzzing microcontroller. The costs that incurred was we took a lot of time during the design document phase to iron out our approach that we could’ve been used developing. Now we have to take time out of Spring break to catch up on our lost time.

Requirements had to be set in order to have a goal for our project. We need to work within the constraints because it limits what we can do and how we can approach the problem. Before we made this change, most of it was that we could basically try any approach and any solution was valid. Now that we have defined memory and timing constraints, we can work to improve the code that we already have.

 

Provide an updated schedule if changes have occurred.

The Gantt Chart has not changed for this week.

Gantt Chart

This is also the place to put some photos of your progress or to brag about a
component you got working.

John Paul Harriman’s Status Report for 3/7/2020

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

Considering the deliverables that I set forward for last week, I have met expectations for most of what I had. The remaining parts order has been placed and we found a better Wi-Fi modules that is higher compatibility and cheaper than the previous one that we had. Protocols loaded to the components has not been accomplished as the parts have not arrived. Packet generation scheme has been described except for address checking so we can make sure that the components we are writing to are correct.

The algorithms for wrapping is done at least for the defined packet sizes. We will be taking a similar approach to what we had for the hamming encoding aspect except for higher integrity by using the Reed Solomon approach instead

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

With the new additions and a redistribution of work, I think we are on schedule for now but depends on how the spring break goes.

 

What deliverables do you hope to complete in the next week?

Deliverables for next week are the Reed Solomon algorithm for the defined packet length to be completed in C so that we can just move it onto the components and run the same software as intended. Post coming soon explaining how Reed Solomon works and why this will be our final choice.

John Paul Harriman’s Status Report for 2/29/20

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week I focused mainly on our plan of attack for the serial communication protocol. It became very apparent that our initial proposals of turbo and LDPC would be too computationally heavy for what we would want for the microcontrollers specified.

I found some substitute algorithms for the two different serial approaches, these will be described in more detail in our design document, but we plan on using more lightweight approaches for both which will max out our code rate to at most 1/2, but still keep us within our new constraint of under 1 second in total.

The solution approach we are going with for now with defined packet sizes such as UART and I2C have a new packet definition with 4 encoding bits to help minimize the chance of error failure, but still keep our code rate at 1/2 for now.

Most of the work has been put into the design document for this week.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I would consider the project on schedule for right now, with it possibly being slightly behind. I realized we did not actually have to implement the protocols themselves as that would be where a lot of the time would go, and just use standardly defined libraries before we try to modify.
Packet generation for now should be trivial as it’s randomly generated bits.
Us changing how we do our architecture did set us a little behind because now we must make sure we have 3 different components running for every protocol to accurately test.

 

What deliverables do you hope to complete in the next week?
Deliverables is as follows:
  • Order remaining parts.
  • Have all protocols loaded onto the components with wires connected
  • Run packet generation and acceptance on these protocols.
  • Begin writing algorithms for wrapping.

 

John Paul Harriman’s Status Report 2/22/20

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I worked on the general structure for what we want to design for I2C.

Most of my work will be under this post I2C Suggestion.

We had to rethink how we were setting up the general structure for these serial protocols. For the most part, we figured that we needed a wrapper for most of the data transmission as passing single data frames is neither space nor time efficient. This is shown in the presentation, but is not a fully solved problem.

I’m having trouble deciding where we should cutoff for constraints vs motivation. In my mind, it very rarely seems like an I2C would want to send more than 255 bytes at any one time, but need to find my justification and reasoning behind it before I commit to the limitations.

I also worked on the design presentation which was formally putting our ideas in a presentable format for next week’s presentation.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We are slightly behind schedule, in my opinion. I wanted to have working code, but the simulation itself is hard to implement.
My plan of action is this:
Write the simulation code for I2C and UART.
Write the packet generation code for I2C and UART.
Write the wrapper function for I2C.
If I can get these goals done, then I will be able to catch myself back up since we should be able to just transfer my code onto the real hardware.

 

What deliverables do you hope to complete in the next week?
Listed above.

 

API Rough Draft Overview

We have partitioned our API into two parts of control and status. Since our current plan is to implement our GUI and Microcontroller to run micro-python, the API examples will be in Python3.

Control from GUI:

We are defining two different ways to control from the GUI, either by bits or by packets. API sketch below:

 

Status from MCU:

We are sending status to the computer only in one command, which is sendStatus. API sketch below:

Team Update for 2/15/2020

What are the most significant risks that could jeopardize the success of the project?
Our biggest risk currently is getting our specific requirements down for what goal we want to accomplish.

We want to be able to create an interesting problem while still meeting the project specs of CubeRover, so we’ve decided to add more rigorous measures that will expand on the current protocols. For instance, in order for Turbo Coding to be truly effective, we must send large data such that our added computation is worth the clock cycles to run.

Another risk that could jeopardize the success of the project is the learning curve for understanding and implementing complex error detection and handling algorithms that all of us are somewhat experienced and familiar.  All of us have some experience implementing error detecting and correcting algorithms for data transmission, but to achieve our goal of finding and writing the best algorithms for what we want to achieve, we may be spending an unexpected and  greater amount of time implementing such algorithms.

How are these risks being managed? What contingency plans are ready?

The risks are being managed by circumventing most of our outside influence. We are planning to take the essential functions asked to be delivered by CubeRover without only working within the scope of their project. Our contingency plan is that if we do not get all necessary documentation to implement along with their specifications, then we will make the decisions ourselves on what to implement, keeping their core instructions intact. For instance, if we are unsure of whether we need to implement a small number of data packets being sent or a large number, they have different trade-offs depending on implementation, so our goal is to implement a valid solution and verification for both so that we don’t have to spend any time waiting for communication between teams.

The risks will be managed by recognizing when the implementation of certain algorithms may be too difficult and unfit to implement for our project and begin slowing down the progress of the project.  If we find ourselves in this situation, the contingency plan will be implementing another algorithm that will successfully error detect the effects but won’t be ultimately optimized to meet the constraints of the project; actually writing the algorithms and verifying that error detecting and handling is successful is upmost priority, and then, we can begin figuring out how to optimize the program given a working program.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?

There were changing made to the existing design because we added a different way to interface with our Microcontroller from our Computers which will be UART or USART.

Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

This change was necessary because the current USB slot is being used for loading the program onto the microcontroller, it also adds ease of use to interface through UART.

Provide an updated schedule if changes have occurred.

Our updated Gantt Chart parallelizes the work that we are doing so that we have more time to work on individual responsibilities while still being on schedule.

This is also the place to put some photos of your progress or to brag about a
component you got working.

John Paul Harriman’s Status Report for 2/15/2020

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

A lot of the work I did this week was formally putting our meeting work together into a digestible format. I also did more thorough research on what specific error correction code we were going to use since there are multiple benefits and drawbacks to each. LPDC was our frontrunner in the beginning, but we are now shifting towards Turbo Codes since it has become the space pseudo-standard.

You can check out my formal proposal for such a use here.

I also went ahead and re-verified the parts we were using before our plan of purchasing in which I added a new, necessary peripheral in order to act with our microcontroller, which is a USB to TTL connection to help interface with the SMT Microcontroller via UART.

Our group collaborated on what our overall structure is going to be, but I formalized it here.

Our group collaborated on what our overall API is going to be, but I formalized it and reformatted to a more UART-centric format here.

The Turbo code formatting is not well-documented on it’s implementation so that is where the majority of my week went into. Figuring out how exactly to implement this ourselves and deciding whether this will be a viable solution in the long run.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

According to our initial Gantt chart, we are behind on our progress. We are planning to do order our parts as soon as possible which will allow us to begin our deployment onto each component. The other is while we are waiting for our parts to ship, we hope to do a pre-simulation without outside peripherals which will only be functions running within the command line. We have allowed ourselves a little slack since we initially planned for a sequential implementation instead of parallel, but I would personally like to be much further along in the project.

What deliverables do you hope to complete in the next week?

My deliverable for the next week is to submit the order forms for all the necessary parts. Then start with a base implementation of I2C that will allow passing of data frames between two instances running. Then be able to add error insertion into the protocol through a middleman instance, which will finally be able to detect error. I’m limiting just to error detection for now so that we can establish our upper-bound of our error correction, which is just asking to send the packet again.

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.