Team Update 2/29/2020

What are the most significant risks that could jeopardize the success of the project?

The most significant risks at the moment is going with a centralized/decentralized design that may have unexpected consequences.  Our team has been discussing which design to go with for so long, and because of the back and forth, we have already wasted time figuring out which one to go with and since both designs have drawbacks, we may run into more issues than we anticipate.  Moreover, we currently are still missing cables that are preventing us from uploading code to the STM32, hindering our progress by preventing us from simulating and testing our code.
How are these risks being managed? What contingency plans are ready?

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.

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

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.

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

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.

Provide an updated schedule if changes have occurred.

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *