John Paul’s Status Report

John Paul Harriman’s Status Report for 5/2/2020

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I implemented a couple more algorithms based on Reed-Muller error correcting code. This algorithm is able to emulate a lot of the most basic error correcting codes by tuning different parameters within the function. I also worked on integrating this added functionality within the GUI.

The video has also taken up a significant amount of time this last week so the team and I have been focusing on that the most.

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

We wanted to get the GUI as fleshed out as possible before making the video, so we are a little behind because the video will still take a significant amount of time before we can send it in.

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

Hope to get the project code finished up, write the report, and finish the video!

John Paul Harriman’s Status Report for 4/25/2020

I rewrote a lot of the existing code I had to be more easily integratabtle into our current GUI solution with an Object oriented approach to create our Test Suite where we will be displaying the graphical information, the data being generated, and the functions working. I can show the packets that I’ve generated, but I’m still trying to figure out a good way to display the information to the viewer that isn’t just a million bits at a time. I’ve worked with the team to hammering out our system construction so all that’s left is just throwing more algorithms at our test suite, displaying information, and continual integration with the team.

I did a lot of work on refining the GUI and the displaying of data in an easy to see format.

This is an example of the data generated in three steps with a chance of a bit flipping being 1/12. The first bar is the generated data of 8bit packets set to grey scale, the second bar is the corrected data that the decoding algorithm has performed on the encoded fuzzed data, the third bar shows the difference between these two bars with white meaning that the data has been correctly decoded and black meaning that it has either corrected the wrong data or could not be fixed.

I also worked on performance benchmarks since we are working to meet the requirements of less than 1mil instructions, my simple encoding and decoding functions for hamming show these results.

I ran my encoding and decoding functions 1000 times and plotted in a histogram. The cycle count is well within the limits, but we will need to test the remaining algorithms to see how they perform.

I also tried to package the gui into its own executable, but did not have success. I think a thorough documentation on how to get started will suffice though.

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

Project seems to be on schedule, just need to implement and test more algorithms.

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

More algorithms! Shouldn’t be too bad.

John Paul Harriman’s Status Report for 4/18/2020

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

Project seems to be on schedule for once, just need to stay on top of things before the demo.

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

More algorithms and proper benchmarkings, I know the number of packets generated in one second, which highly exceeds current expectations for timeouts, but want exact numbers.

John Paul Harriman’s Status Report for 4/11/20

I worked more on getting the demo ready and then on the concerns post-demo. I was able to display the information in real time of the exact rate of successful packets recovered, but was suggested that I should also be able to see the data that is being fixed. I had some concerns about doing this since I am doing around 1000+ packets per second and could overwhelm the user, but I think I have thought of a way of displaying this information. My work now has been trying to show the fixed and unfixed packets side by side as a stream into a window clickable by the user. I also worked on further research on forward error correcting codes.

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

In terms of my personal schedule I’m a little behind because I wanted more integration to be done, but will need cooperation with the entire team to accomplish that. Just in general I need to put in a lot more of these correcting algorithms since I’ve figured out the system construction.

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

Deliverables are integration of API into GUI, more algorithms, and benchmarking the algorithms that we do have. (Same as last week)

John Paul Harriman’s Status Report for 4/4/2020

I implemented most of the base calls for the API and implemented the algorithm for hamming encoding/decoding.

Here is a link to the current files of implementation: Here

These files aren’t up to production documentation, but that is more of back-burner problem right now.

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

I think that we are on schedule, but still have a lot of work to do. The main thing that will potentially bring us down is the ethics reading, demo, video, and final report. These are all projects that take significant amounts of time to get ready and can take away from what we are doing in terms of coding. This is why I will suggest that we crunch after the demo so that we can get everything in on time.

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

Deliverables are integration of API into GUI, more algorithms, and benchmarking the algorithms that we do have.

John Paul Harriman’s Status Report for 3/28/2020

I was able to start actually implementing our code!

I did a lot more research into what exact error correcting codes that we could use for our defined packet model. I’ve been going deep into this rabbit whole of which one is the best to use so hopefully next week I can start connecting the dots between all of them. I wrote the code for defined packet generation with a new model.

This model helps us gain easier access to verification by storing it in a struct because we now don’t have to pass all of our data through the specific wires and can focus on correction/detection and protocol handling.

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

I personally think we’re catching up, but still have a lot to do. If we can start getting algorithms down for correction/detection then we can have a successful project.

I’m going to do my part now which is gathering all the different algorithms and hopefully link up with my teammates over the next week.

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

Deliverables for next week are the Reed Solomon algorithm and others for the defined packet length to be completed in C, but without the additional component interactions.

I kind of switched my paths halfway through so I’m going to keep these goals.

John Paul Harriman’s Status Report for 3/21/20

With the end of Spring Break moving into the transition into the remote classes, most of my work has been getting my life back together and also trying to make the transition with Capstone.

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

I’m not sure if we are now on schedule or we were just forced to move the goalpost. As we move toward the simulation aspect of our project now, a lot of the stuff I was researching about the interactions between components is now basically scrapped. This project can be successful but I don’t think will be what we originally intended.

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

Deliverables for next week are the Reed Solomon algorithm and others for the defined packet length to be completed in C, but without the additional component interactions.

John Paul Harriman’s Status Report for 3/7/2020

Considering the deliverables that I set forward for last week, I have met expectations for most of what I had. The remaining parts order has been placed and we found a better Wi-Fi modules that is higher compatibility and cheaper than the previous one that we had. Protocols loaded to the components has not been accomplished as the parts have not arrived. Packet generation scheme has been described except for address checking so we can make sure that the components we are writing to are correct.

The algorithms for wrapping is done at least for the defined packet sizes. We will be taking a similar approach to what we had for the hamming encoding aspect except for higher integrity by using the Reed Solomon approach instead

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

With the new additions and a redistribution of work, I think we are on schedule for now but depends on how the spring break goes.

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

Deliverables for next week are the Reed Solomon algorithm for the defined packet length to be completed in C so that we can just move it onto the components and run the same software as intended. Post coming soon explaining how Reed Solomon works and why this will be our final choice.

John Paul Harriman’s Status Report for 2/29/20

This week I focused mainly on our plan of attack for the serial communication protocol. It became very apparent that our initial proposals of turbo and LDPC would be too computationally heavy for what we would want for the microcontrollers specified.

I found some substitute algorithms for the two different serial approaches, these will be described in more detail in our design document, but we plan on using more lightweight approaches for both which will max out our code rate to at most 1/2, but still keep us within our new constraint of under 1 second in total.

The solution approach we are going with for now with defined packet sizes such as UART and I2C have a new packet definition with 4 encoding bits to help minimize the chance of error failure, but still keep our code rate at 1/2 for now.

Most of the work has been put into the design document for 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 would consider the project on schedule for right now, with it possibly being slightly behind. I realized we did not actually have to implement the protocols themselves as that would be where a lot of the time would go, and just use standardly defined libraries before we try to modify.

Packet generation for now should be trivial as it’s randomly generated bits.

Us changing how we do our architecture did set us a little behind because now we must make sure we have 3 different components running for every protocol to accurately test.

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

Deliverables is as follows:

Order remaining parts.
Have all protocols loaded onto the components with wires connected
Run packet generation and acceptance on these protocols.
Begin writing algorithms for wrapping.

John Paul Harriman’s Status Report 2/22/20

I worked on the general structure for what we want to design for I2C.

Most of my work will be under this post I2C Suggestion.

We had to rethink how we were setting up the general structure for these serial protocols. For the most part, we figured that we needed a wrapper for most of the data transmission as passing single data frames is neither space nor time efficient. This is shown in the presentation, but is not a fully solved problem.

I’m having trouble deciding where we should cutoff for constraints vs motivation. In my mind, it very rarely seems like an I2C would want to send more than 255 bytes at any one time, but need to find my justification and reasoning behind it before I commit to the limitations.

I also worked on the design presentation which was formally putting our ideas in a presentable format for next week’s presentation.

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

We are slightly behind schedule, in my opinion. I wanted to have working code, but the simulation itself is hard to implement.

My plan of action is this:

Write the simulation code for I2C and UART.

Write the packet generation code for I2C and UART.

Write the wrapper function for I2C.

If I can get these goals done, then I will be able to catch myself back up since we should be able to just transfer my code onto the real hardware.

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

Listed above.