What are the most significant risks that could jeopardize the success of the project?
The most significant risks that could jeopardize the project is still working separately as a team and all of us being in different time zones; because of this situation, communication takes longer and more planning. Additionally, possibly being overambitious last week may jeopardize the success of the project. This week, we regrouped as a team and after taking in the feedback from our meeting, we realized that it was important to simulate and verify our protocols using a GUI; thus, we shifted our attention to the GUI and adjusted the Gantt chart accordingly.
How are these risks being managed? What contingency plans are ready?
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.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
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:
Additionally, after further research, we have decided that we might not be going with the Reed-Solomon implementation for I2C/UART. We’ve decided to experiment with the various protocols to determine whether we should continue with that implementation or not.
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
The change was necessary because we are no longer running our software on the drivers; since our project is now simulated, we had to redesign slightly modified transactions between the GUI and the protocols. Additionally, last week, we didn’t think that we needed a GUI to simulate and verify our protocols with; we thought test benches would be sufficient. However, after several discussions this week, we realized that we should bring the GUI back.
Because we will be spending more time integrating the protocols with the GUI and creating the GUI, we will not be able to implement as many protocols as we like. Our initial plan was ambitious though, and since we’re already finished with at least half the protocols, we were able to make time to create and integrate the protocols with the GUI. To mitigate these costs, we plan to no longer make large changes like these to our design and since everything has been re-prioritized, we hope to stick to those new decisions.
Provide an updated schedule if changes have occurred.
This is also the place to put some photos of your progress or to brag about a component you got working.
GUI:
