Mia Han’s Status Report for 3/7/20

What did you personally accomplish this week on the project?

This week my team and I spent a lot of time finishing up the design document. There was some confusion on the overall architecture so as a team we spent a lot of time ironing out the details before we submitted. After that we planned out our goals for the implementation phase going into spring break.  Additionally, we decided who would be implementing what parts of project during spring break.  This week, I began writing some code for the GUI implementation and wrote at least 1/3 of the functions for the communication using the STM32 cube libraries.

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 on schedule but we have a lot of work to dot before the first demo. I plan on using spring break to make some initial progress on the implementation phase.  During spring break, I hope to at least implement the GUI and MCU communication and protocols; with this completed, we would be able to use the GUI to begin testing the individual components.

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

During spring break, I hope to complete the GUI and MCU interactions and communications over a few days that I plan on completing course work.  Additionally, I hope that those functions are tested and ready to use for testing the protocols by the time school starts.

Sam Adams’s Status Report for 3/7/20

What did you personally accomplish this week on the project?

This week I worked on finalizing the design decisions for the design doc that we submitted on Monday. After that my team and I finished making the final design decisions, I began to work on implementing the UDP packet protocol. I was able to make good progress by implementing the barebones of the protocol. I also met with my team so we could set some goals for spring break as we all plan to do a little bit of work over the break.

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 on schedule. We are done with the design document and we hope to have the initial versions of all of the protocols before our first demo. My goal is to use spring break to get ahead on the implementation phase.

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

I hope to have completed coding the UDP protocol by next week. I want to finish it relatively early so I can help my team with the implementation of the other protocols that we are working on.

Team Update 3/7/2020

What are the most significant risks that could jeopardize the success of the project?
Most of the problems that we were at risk for last week were successfully solved.
Our new risks come with the learning curve of using our new components that we ordered because there hasn’t been a way to really interact with them if we did not physically have them.
Besides that, we believe that we should be okay. We still need to figure out which addresses to write to and how exactly we will set up the components to interact with each in terms of where they will write data to, read data from, etc.
How are these risks being managed? What contingency plans are ready?

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.

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

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.

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

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.

 

Provide an updated schedule if changes have occurred.

The Gantt Chart has not changed for this week.

Gantt Chart

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

John Paul Harriman’s Status Report for 3/7/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).

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.

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.

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

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).

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.

 

Mia Han’s Status Report for 2/29/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).

At the beginning of this week, my team and I were putting the final touches on our design presentation; I was last-minute finding the best ways to measure latencies on the STM 32 and making sure that the GUI + interactions diagrams were finished and looked good.  When I was looking into how to best measure latencies, I found that we can use oscilloscope via an unused pin, hardware timers: Hal_tick/sys_tick, TIMx, or analyze assembly code + count clock cycles.  Finding multiple ways to measure the latency provides flexibility with our verification so that we aren’t dependent on one method if another method falls through.  Additionally, it allows us to verify that  the latency measured is correct by being able to verify through multiple ways.

Once the presentation was done, we realized that the GUI + the interactions between the components were good and more focused needed to be put towards the actual implementation of the protocols.  Therefore, I took over the stream of bits (GPIO + SPI) protocols since my teammate will focus his efforts on the serial data transmission (I2C + UART).  I felt that my work on the GUI was mostly done and I wanted to help off load some of the work from them.

Regarding the protocols for streams of bits, I determined what the constraints should be for stream of bits by finding implementations of convolutional codes with the Viterbi algorithm online that is most similar to what our implementation would be.  With testing of various code rates and constraint configurations for passing 113 bits, the average latency was 0.004 seconds, which will be our goal latency;  113 bits = 13 bytes is the amount of bits that CubeRover is currently expecting to pass through SPI and GPIO.  Additionally, we determined how the code rate will be determined; after researching the best code rates for convolutional codes, I realized that it will ultimately vary and it will be best to try out a handful of code rates (1/2, 4/7, 6/7 etc) to determine which one is best.  Like the code rates, the constraint will be determined by testing various values to determine which one the lowest latency.  Moreover, my research solidified choosing the Viterbi algorithm + convolutional codes since Turbo Coding and LPDC are best for streams with a high throughput and since CubeRover is not expecting a high throughput, using convolutional codes is the best fit.

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

I believe that my progress is behind schedule; ideally, I would have liked to begun coding already but because we forgot to order a cable, I can’t upload any code to the STM32 yet.  Despite having the GUI and software + hardware interactions figured out, I feel that we are behind with a lot of the specifications for the protocols which was also communicated to us through the presentation feedback.  Additionally, because we kept deciding between a decentralized model vs a centralized model, those discussions hindered our work and took up time that we could have spent working on other components.
What deliverables do you hope to complete in the next week?
The design document is due Monday night, so that will be for sure completed with the correct specifications listed as that was the biggest critique of our feedback from the presentation.  I would like to begin either working on the GUI or convolutional codes with Viterbi; I am meeting with my teammates tomorrow discuss what components should be prioritized to work on.
Minimum Goals For This Week
– Draft of Convolutional Code + Viterbi Algorithm
– Create Functions that can read/write data bytes to STM32 from GUI

 

Sam Adams’s Status Report for 2/29/20

What did you personally accomplish this week on the project?

This week I focused on following up on the feedback that we got during our design presentation. This involved getting more concrete metrics that can be used during the creation of our design doc. To do this I spent most of my time researching the procedures and devices being used by the CubeRover team in order to set the scope of the UDP design. After this I was able to go over my design again with a fine tooth comb in order to make sure that all the requirements were being met and that we were in scope. I also spent time creating a backup plan incase we ran into problems implementing the design.

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

I ended up getting a little behind this week. The peer reviews from the design presentation were eye opening and we realized we had to make some design changes before we submitted the design doc and started the implementation phase. In order to make up for this week I am planning to do a lot of work over spring break in order to catch up on the implementation phase.

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

This next week I want to start the implementation of our design. My goal is to be able to pass some simple benchmark tests by the end of the week (such as sending and receiving basic packets on our MCU). This would give me a big leg up on the implementation phase as I would be able to start adding the more complicated features and optimizing in the weeks following.

Overview of User Datagram Protocol (UDP) Design

When approaching this design I wanted initially to implement a full TCP protocol using UDP packets. This would essentially work by using the body of the UDP packets to store the information needed for the TCP protocol. This would provide a way to retrieve lost packets. I settled on the packet design below:

Packet Design

Protocol Design

While this data exchange looks to be the exact same at a standard TCP protocol, the key is that it will be performed using UDP packets. Doing this parts of the design will have to be limited as we will not have to deal with cases where we have to do intense tasks such as streaming video.