Category: Team Status Report

These risks are being mitigated by setting times during the week that we will consistently meet at.  This will force us to routinely regroup and will facilitate discussions that were previously delayed because of lack of planning.

The contingency plan is to get the GUI working + properly simulating the protocols and writing at least the convolutional codes + viterbi, UDP with windowing, reed solomon, and Turbo Codes.  We realized that we should include a GUI regardless; therefore, we are prioritizing the creation and integration of the GUI over the addition of more protocols.

We’ve slightly restructured the interactions between the protocols and GUI.  Because we are no longer integrating with the hardware, we’ve simplified and modified how data will be exchanged between the GUI in Python and the protocols in C.  For the GUI implementation, we’ve decided to use PyForms, a library that provides a clean-looking GUI.  We plan on using a library, ctypes, that allows for C functions to be called in Python.  We’ve made a new diagram that illustrates the new exchanges between the protocols + the GUI: 

GUI: 

This is not a risk we really could’ve managed given the circumstances, but our suggested contingency plan is stated in the Statement of Work.

This change was necessary because of Covid-19 affecting the physical proximity of the teammates and recognizing the physical aspect of the project would only put physical strain on one teammate instead of the team.

Since we’ve already lost time redesigning our project, we realize that we need to immediately recognize whatever problems that may arise; because we’ve already lost so much time redesigning our project, we can’t afford to loose any more time running into issues or rethinking our current implementation decisions.

The biggest issues moving forward are not being together, making communication significantly harder amongst team members; additionally, some of us are in different time zones, making meetings harder to arrange.  Thus, to mitigate these costs, we have set up weekly meeting times that work for all of us regardless.  Additionally, we are clearly and frequently communicating to each other should any issues arise immediately.

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.

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.

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.

The Gantt Chart has not changed for this week.

Gantt Chart

The risks are being managed by acknowledging and understanding the fact that we really need to determine which design to go with to prevent further hindering of our progress (we are meeting tomorrow to discuss this).  Additionally, moving forward, we need to be more careful and check to make sure that we order all the components that we need when we place our orders.  For now, we need to make sure that we order this cable ASAP during class on Monday.  With the risks that come with both designs, we need to discuss and thoroughly justify which design to go with; by thinking through both designs and reasoning which one makes more sense with our various components, we hope to mitigate and foresee any issues that may arise.  Additionally, while implementing each of our individual protocols, we need to keep in mind how each of our components will fit into the design and if any issue or complication is realized while creating the protocol, we should notify each other and discuss the issue immediately.

We have a new constraint of fitting within the time for a timeout – which includes both the transmission time and the error correction time.

The design of the system also changed to a previous approach after consultation. We moved more towards a unit testing approach to streamline how we were testing the protocols, but a pass-through approach with our ‘fuzzing’ microcontroller would be more accurate to the system we are trying to emulate. This new design will be reflected in our design document.

Our timeout was necessary because now we have working constraints to work with. If we had infinite compute time, then we could use any algorithm, but since we are more focused on the aspects of power and time, we should use the real scenario in which it will operate.

That’s also why we changed our overall design to match a more realistic approach and help us move toward our three step plan of a working product.

Neither of these changes should have a higher cost.

We do need to find a new wifi module for our TI Hercules, but this will only bring cost down because we will not have to buy as expensive of an evaluation board to achieve the same results.

We adjusted the GANTT chart to account for the individual testing of each component’s protocol and data transmission (the phases that were discussed during the presentation).

Gantt Chart