Author: miah

Mia Han’s Status Report 5/2/20

What did you personally accomplish this week on the project?

Once I started writing the final report and began looking more into my implementations, I realized that I didn’t implement the right Reed-Solomon version; instead, I implemented a combination of viterbi + rs which is why the accuracy was so high for errors less than <10%.  So, I re-did the reed solomon implementation that more accurately reflects the actual implementation.  Additionally, I implemented BCH, another algorithm that detects errors within certain packet sizes.   Moreover, we met a couple times as a group to make sure everyone understood the GUI, how to integrate their portions, and how to go about de-bugging our issues.

I also worked on our final presentation earlier 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 feel that we are slightly behind; the actual product is almost finished, but I’m worried that we are a bit behind on our video.  Additionally, I’m a bit rusty on C, so that was a little hurdle I overcame today.

To catch up, I plan on spending all day tomorrow creating the script and video that’s due Monday.  Moreover, now that I’ve overcame that hurdle, I feel that it should be smooth sailing from here.

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

I hope to (in order of priority):

  1. Clean up RS
  2. Maybe implement a nuanced version of RS
  3. Finish the video
  4. Final Report

Mia Han’s Status Report 4/25/20

What did you personally accomplish this week on the project?

I worked on converting getting my protocols to convert from static calls to repetitive calls every second to display on our live graph; additionally, I integrated JP’s graph with my implementation of the GUI.  I also collected data that verifies that my protocol meets the requirements that we set at the beginning of the semester- everything looked good!  I also fixed the Viterbi + convolutional codes implementation to verify the accuracy of the data that was recovered and not just measure the number bytes of data that was recovered.

I then spent the latter half of the week working on our presentation that is due Sunday night.

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

I feel that we are slightly behind; I hope to finish up at least one more protocol implementation before the video of the final product.  But, because we spent some time figuring out how to integrate the protocols with the GUI and the best way to present the data on the GUI, I feel that I am a bit behind.

At this point, a few of my classes have already wrapped up, so I plan on spending this extra time working on this new protocol and making sure the everything that I have already written is near perfect.

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

I hope to (in order of priority):

  1. Reintegrate my Viterbi and RS implementations with the new GUI
  2. Finish gathering the measurements for the presentation tonight
  3. Implement one more error detection and correction protocols that we previously discussed in our project re-design.

Team Update 4/18/20

What are the most significant risks that could jeopardize the success of the project?
The most significant risks right now are not fully debugging the GUI, leading to an unexpected error; at the moment, the core error detection and correction algorithms are solidified, so the GUI may need to go through more rigorous testing.  Additionally, since the UDP protocol implementation is much different than the serial and bit streaming protocol implementation, a potential issue may be integrating the UDP protocol with the GUI taking longer than expected.
How are these risks being managed? What contingency plans are ready?
The risks are being managed by making the components between the GUI and algorithms as clean as possible; we’ve created an easy to use class that wraps around the protocols, making integration and debugging as simple as possible.  The contingency plan for not integrating protocols with the existing set up is creating a separate GUI/method of simulating those results.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
Nope- we’re still on track with the current design that we have and so far the implementations are working as expected.
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We were deciding between a dynamic approach like JP’s graph demo and a non-dynamic/on-click approach like Mia’s approach using a console to display data; we’ve decided to go with a dynamic approach, since it more accurately simulates the accuracy rate during serial data transmission and was easy to make the bit streaming algorithms dynamic.  Rather than simulating one transmission of data by clicking the button, clicking the button will only change the protocol currently being simulating, while the actual transmissions are continuously going + results are constantly being graphed and displayed.

Provide an updated schedule if changes have occurred.
The schedule has not changed.

Mia Han’s Status Report 4/18/20

What did you personally accomplish this week on the project?

We met a few times this week to discuss who would be responsible for the remaining tasks and how to begin integrating each other’s work.  I felt that it was best for me to integrate the graph with the GUI, while JP worked on writing a nice wrapper class to encapsulate the protocols and make calling each protocol from the GUI a lot easier and neater.

I integrated the line plot graph with the GUI; now, the results from each iteration of the protocol is plotted in the graph in real-time (thus, the graph from JP’s demo and the GUI from my demo are in one nice GUI!).  Additionally, I’ve finished implementing and integrating Reed Solomon simulation.

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

I feel that our progress is on schedule; we spent a good amount of time ensuring that any protocol can be easily integrated with the GUI, and I’m satisfied with those results.  Additionally, since the integration is mostly completely, I feel that we can focus more on creating more types of encoding and decoding schemes.  I’m a little worried about the UDP integration with the GUI putting us behind schedule, since that is so different than the current serial/bit stream implementations that we’ve currently integrated.

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

I hope to (in order of priority):

  1. Ensure that there are no bugs in the GUI- right now, we are getting a few bugs every now and then.  Additionally, I would like to clean up the GUI by adding more console messages and figuring out if it is possible for the graph to be updated more quickly.
  2. Implement more error detection and correction protocols that we previously discussed in our project re-design.

Team Update 4/11/2020

What are the most significant risks that could jeopardize the success of the project?
The most significant risks at the moment was the lack of communication between team members; right now, we’ve been working on our components individually, making integration a bigger task than it should have been.  Achieving cohesion by combing all of our implementations into a GUI is the biggest priority right now.
How are these risks being managed? What contingency plans are ready?
The risks are being managed by setting up a bunch of meetings to discuss how each other’s implementations of the protocol work to ensure quicker understanding of each other’s code.  Additionally, we are making sure that our code is clean and well-documented so that it’s easier for each other to understand how we’ve implemented the algorithms.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
Nope- we’re still on track with the current design that we have and so far the implementations are working as expected.
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We’ve not made any changes this week!

Provide an updated schedule if changes have occurred.
The schedule has not changed.

Mia Han’s Status Report for 4/11/20

What did you personally accomplish this week on the project?

I’ve been working on refining the prototype demo-ed on Wednesday by further testing my program and debugging it from minor issues.  Additionally, I’ve been working on implementing other algorithms like Reed-Solomon and integrating the Hamming Codes + graph and UDP protocols.  I also did my reading for next Wednesday’s discussion 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 feel that our progress is slightly behind; I would like to further along with the integration, but I feel that putting in a few more hours this week will put us in a good spot.

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

I hope to (in order of priority):

  1. Integrate the hamming codes implementation + UDP protocol with the GUI and integrate the graph feature
  2. Finish debugging and refining GUI

Team Update 4/4/20

What are the most significant risks that could jeopardize the success of the project?
The most significant risks right now is our shallow understanding of these algorithms; most of the issues being encountered are related to algorithm implementation, causing longer debugging times that we anticipated.  Additionally, a lot of our classes are beginning to pick up as the end is in sight, so we’ve been juggling the work with this class with the work with our other courses.
How are these risks being managed? What contingency plans are ready?
The risks are being managed by looking at more examples and trying to better understand the ways that these algorithms can be implemented; additionally, we’ve found youtube videos really helpful with explaining these concepts.  Moreover, I feel that clearer communication has facilitated debugging, since asking each other for help and using each other to debug has been helpful.
Since the end is in sight more than ever, we feel that we’ve prioritizing other projects based on deadlines, and since this assignment is the soonest deadline for all of us, we really want to make a big push this weekend + beginning of next week before things pick up again.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
No- after our discussion last week of not making any more revisions and being confident & set on our current design, we have not made any significant changes to our design.
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We’ve not made any changes this week!

Provide an updated schedule if changes have occurred.
The schedule has not changed.

Mia Han’s Status Report 4/4/20

What did you personally accomplish this week on the project?

I’ve been working on integrating my protocol with the GUI.  I’ve ran into more issues that I was expecting; I feel that my issues have arose from forgetting small things in C and relearning a few concepts.  Additionally, our team met a few days ago to discuss how we are going to approach integration and what unforeseen tasks need to be addressed.  Ultimately, I’ve spent this past week refining my protocols and integrating it with the GUI; moreover, I’ve been helping my team understand the GUI and the plan for how it all should be integrated.

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

I feel that my progress is a bit behind; because of my rustiness with C and learning along the way with these algorithms, I underestimated slightly the difficulty of implementing these.  These algorithms are a lot more complex to implement than understanding.

To catch up, I’ve committed spending the time now until the demo to integrate, test and debug our protocols.  I feel that I can make a big push before things get too hectic with my other coursework next week, and now that we have a clearer vision for what we are planning to do, I feel that I can complete those tasks with more confidence.

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

I hope to:

  1. Refine the GUI
  2. Integrate the viterbi + convolutional codes and hamming codes implementation with the GUI

Team Update 3/28/20

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: