Tag: Team Status Report

Team Update for 2/22/2020

What are the most significant risks that could jeopardize the success of the project?
Like our previous post discussed, the biggest risk right now is being able to narrow down the tough to quantify requirements of the project.  For instance, we are having a hard time determining the percentage of packet that should be deemed unrecoverable.  Since all of us don’t have the deepest understanding of error handling and correcting, we are having trouble defining what is considered a recoverable data packet in our protocols.  Additionally, we don’t know what is considered a reasonable amount of latency for our protocols to error detection/correcting and between sending and receiving data packets.
How are these risks being managed? What contingency plans are ready?

Right now, we are prioritizing actually implementing the protocols and focusing on making sure the transactions are accurate and work.  Once those portions are implemented successfully, we will begin refining our protocols and seeing which one can be better optimized.  With better understanding of how error correction/detection methods, the requirements of the project should be more apparent given our better understanding of how much each protocol is capable of.  We will consider what CubeRover would like for the requirements to be, but ultimately, we will use our knowledge and research to narrow down what the requirements will tentatively be by tomorrow night.

Should we not be able to determine what requirements are reasonable for our prototype, we will attempt to minimize latencies and maximize the amount of packets recoverable as best as we could.  We plan to analyze each portion of our protocols to see which could be better optimized regarding time and space usage.

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

We didn’t make any changes to the existing design, but we did consider other designs that the professor and TA brought up.  While considering other designs, it reaffirmed our beliefs and justifications regarding why we are sticking to the original design.  Additionally, we added more details to the GUI’s functionality; we specified what exactly the GUI will be sending and receiving and what the communication between all components will be.

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

The change to the GUI was necessary to detail what we are doing and necessary to determine the best way to implements such ideas.  Moreover, these details have also dictated what other components will be doing, thus affecting other implementation choices in our design as well.

No significant costs have been incurred since we are still in the Design Phase of our project.  However, going back and forth between different system designs did hinder the development of the implementation detail development like which API’s and libraries to use.  These costs will be mitigated by making design choices more quickly to prevent a pushback of tasks and by being able to justify and research into decisions more thoroughly.

Provide an updated schedule if changes have occurred.

No changes have occurred; the original Gantt chart is attached.

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

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.