Author: miah

Statement Of Work

We believe that most of our original project can be maintained, since the crux of the project is software that will be loaded onto CubeRover’s modules.  Since we can no longer simulate the protocols using physical components, we intend to simulate the protocols. Because the hardware aspect is no longer feasible, we plan on re-focusing our project to create, implement and test various error detection and correction algorithms to determine which methods best meet CubeRover’s specifications and hardware specifications.  Creating these various error detection and correction protocols are the priority; a stretch goal would be creating the GUI to make our error detection and correction simulations more presentable.

Error Detecting and Correcting Algorithms that we will be creating and testing:

I2C + UART GPIO + SPIO Wifi
  1. Reed Solomon
  2. Hamming Code
  3. Low-Density Parity Check Code (LDPC)
  4. BCH code
  1. Turbo Codes
  2. Convolutional Code + Viterbi
 1. TCP over UDP w/o windowing

2. TCP over UDP w/ windowing

 

Currently, we’ve decided to start looking into and implementing Forward Error Correction Codes, LDPC Codes, and Turbo Codes; a reach goal is researching and implementing other error correction and detection methods.

Current State:

Right now, we are finished writing and verifying the correctness of the initial error correction and detection methods that we decided on implementing (reflected in our most recent Gantt Chart created before spring break).  Our current implementations, however, are designed to send data to the microcontrollers; we will therefore spend a few days modifying our current implementations to be simulated and verified using test benches. 

Old vs. New Phases:

Old Phases New Phases
  1. Creating the algorithm implementations
  2. Data Verification
  3. Protocol Verification and Throughput Test
  4. Hands-Off
  1. Creating the algorithm implementations
  2. Data Verification
  3. Analysis of tradeoffs/runtimes

We have updated our previous phase plans to reflect the changes that we have made to the project; instead of verifying the accuracy of the data being passed to and from the microcontroller, we will instead shift to writing more algorithms to determine which error detection and correction implementations best fit the requirements of the project.

New Tasks + Splitting New Tasks Between Team Members:

Previous Tasks New Tasks
Mia:

  • GUI Implementation
  • SPI/GPIO: Convolutional Codes + Viterbi

John Paul:

  • UART/I2C: Hamming Code

Sam:

  • Wifi

All: Integration

 Mia:

  1. SPI/GPIO
  • Turbo Codes
  • Convolutional Codes + Viterbi
  1. GUI 

John Paul:

  1. UART/I2C
  • Reed Solomon
  • Hamming Code
  • BCH code

Sam:

  1. UART/I2C:
  • LDPC
  1. Wifi
  2. GUI

Sam Adam’s Status Report 3/21/2020

What did you personally accomplish this week on the project?

Over spring break, I worked on finishing up the wifi-UDP implementation. I also worked with my team to pivot the scope of our project in order to work on it remotely.

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 slightly behind due to the re-designing that we had to do to account for not being able to physically be together to implement the hardware components. However I do feel like the work I was able to get done over spring break puts me into a good spot considering the re scoping of the project.

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

I hope to finish the UDP/Wifi and write sufficient and thorough test benches to verify that I’m properly simulating the error detection and handling. This would free up my time to help out my teammates on the other communication protocols.

Team Update 3/21/2020

What are the most significant risks that could jeopardize the success of the project?
The most significant risk has been not being able to physically be together in Pittsburgh to work on the physical aspects of the project.  Additionally, because of this unforeseen event, we have lost more time to redesigning and shifting our project.  Moreover, because some of us our in different time zones, finding good meeting times for everyone is more difficult.
How are these risks being managed? What contingency plans are ready?

This is not a risk we really could’ve managed given the circumstances, but our suggested contingency plan is stated in the Statement of Work.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
A more detailed account of what we changed is listed in our SOW, but a brief description of the current goal of our project is “we believe that most of our original project can be maintained, since the crux of the project is software that will be loaded onto CubeRover’s modules.  Since we can no longer simulate the protocols using physical components, we intend to simulate the protocols. Because the hardware aspect is no longer feasible, we plan on re-focusing our project to create, implement and test various error detection and correction algorithms to determine which methods best meet CubeRover’s specifications and hardware specifications.”
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

This change was necessary because of Covid-19 affecting the physical proximity of the teammates and recognizing the physical aspect of the project would only put physical strain on one teammate instead of the team.

Since we’ve already lost time redesigning our project, we realize that we need to immediately recognize whatever problems that may arise; because we’ve already lost so much time redesigning our project, we can’t afford to loose any more time running into issues or rethinking our current implementation decisions.

The biggest issues moving forward are not being together, making communication significantly harder amongst team members; additionally, some of us are in different time zones, making meetings harder to arrange.  Thus, to mitigate these costs, we have set up weekly meeting times that work for all of us regardless.  Additionally, we are clearly and frequently communicating to each other should any issues arise immediately.

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.

Mia Han’s Status Report 3/21/2020

What did you personally accomplish this week on the project?

After hearing that we are no longer returning to campus and moving to virtual classes, I paused what I was working on, because I was uncertain where our project would be moving from there; I spent the remainder of spring break working on homework assignments that I knew would not be affected by moving virtually online.  Once we regrouped on Wednesday as a team and with our professor + TA, I began shifting my focus from working on the convolutional codes + Viterbi to restructuring our project and new project proposal.  We really liked the idea of comparing several FEC’s, turbo codes, and LDPC to determine which one best fits CubeRover’s hardware constraints.  Therefore, I spent most of this week deciding which error detection and correction algorithms would be prioritized for GPIO/SPI and finishing up Viterbi + convolutional codes; I also researched the pro’s and con’s of those various algorithms more thoroughly.

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 our progress is definitely behind; already using this week to restructure our project, I believe that we are behind turning our project around and implementing a slightly different version of the project in the next seven weeks.  Additionally, I didn’t accomplish as much work as I would like over spring break, putting me more behind than I was originally expecting; I spent more time brushing up on C/C++ and fully understanding the nuances of convolutional codes + Viterbi than I was originally expecting.

To catch up to project schedule, I believe that I will be able to spend more time on the project, since the quarantine in my town is stricter and there’s literally nothing else to do besides stay home.  Additionally, I spent some time next week worrying about and cancelling future plans; therefore, I feel that getting into the school work grind will begin this week.

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

I hope to

  1. Finish and test convolutional codes + Viterbi implementation
  2. Fully understand and start writing the Turbo Codes implementation

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.

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

 

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

I finalized what libraries will be used to implement the communication between the GUI and the STM32.  With the finalization of what the responsibilities of the STM32 and the GUI communication will be, the ideal library used to implement our design became clearer and easier to determine. I determined what specific libraries and functions will be used to measure the latencies and to interface with the STM32 peripheral, UART.  Measuring latencies was something that we were initially unsure about how to implement, but I began to look into what the stm32cube HAL libraries and microPython libraries offered and realized that both offer libraries that can measure and return the number of clock cycles internally.  Furthermore, I wanted to find implementations that contained libraries that would best achieve what we have and mind and would offer the most useful functions to do so.

A good amount of the work this week has been going into our design presentation.  After discussion with my teammates regarding what design we should go with, we finalized the design and I created multiple diagrams that are used in the presentation.

Final GUI Design:

Interactions Between GUI, MCU, and Components:

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; I feel confident in the design decisions that I’ve made especially after thoroughly discussing them with my team and hearing their thoughts regarding them.  I would have liked to start writing some code this week to see what it’s like using an STM32 and having it communicate with my computer, but unfortunately, the cable to connect over USB didn’t come with the MCU.  To make up for this delay, I intend on spending more hours next weekend when I’ll have more time to begin writing some of the functions for the transactions between the GUI and STM32.  Additionally, by beginning to write these functions, I will have a better understanding of what implementing these functions are like for the Design Report due next week.
What deliverables do you hope to complete in the next week?
I hope to write at least 3-5 functions that will be implemented and I hope to be 110% confident in my design and implementation choices.  Moreover, I hope that I have determined how exactly I intend to implement each function in our design using which languages and libraries.

 

Team Update for 2/22/2020

What are the most significant risks that could jeopardize the success of the project?
Like our previous post discussed, the biggest risk right now is being able to narrow down the tough to quantify requirements of the project.  For instance, we are having a hard time determining the percentage of packet that should be deemed unrecoverable.  Since all of us don’t have the deepest understanding of error handling and correcting, we are having trouble defining what is considered a recoverable data packet in our protocols.  Additionally, we don’t know what is considered a reasonable amount of latency for our protocols to error detection/correcting and between sending and receiving data packets.
How are these risks being managed? What contingency plans are ready?

Right now, we are prioritizing actually implementing the protocols and focusing on making sure the transactions are accurate and work.  Once those portions are implemented successfully, we will begin refining our protocols and seeing which one can be better optimized.  With better understanding of how error correction/detection methods, the requirements of the project should be more apparent given our better understanding of how much each protocol is capable of.  We will consider what CubeRover would like for the requirements to be, but ultimately, we will use our knowledge and research to narrow down what the requirements will tentatively be by tomorrow night.

Should we not be able to determine what requirements are reasonable for our prototype, we will attempt to minimize latencies and maximize the amount of packets recoverable as best as we could.  We plan to analyze each portion of our protocols to see which could be better optimized regarding time and space usage.

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

We didn’t make any changes to the existing design, but we did consider other designs that the professor and TA brought up.  While considering other designs, it reaffirmed our beliefs and justifications regarding why we are sticking to the original design.  Additionally, we added more details to the GUI’s functionality; we specified what exactly the GUI will be sending and receiving and what the communication between all components will be.

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

The change to the GUI was necessary to detail what we are doing and necessary to determine the best way to implements such ideas.  Moreover, these details have also dictated what other components will be doing, thus affecting other implementation choices in our design as well.

No significant costs have been incurred since we are still in the Design Phase of our project.  However, going back and forth between different system designs did hinder the development of the implementation detail development like which API’s and libraries to use.  These costs will be mitigated by making design choices more quickly to prevent a pushback of tasks and by being able to justify and research into decisions more thoroughly.

Provide an updated schedule if changes have occurred.

No changes have occurred; the original Gantt chart is attached.

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

Mia Han’s Status Update for 2/15/20

What did you personally accomplish this week?

After deciding what each team member is responsible for researching, I was tasked to determine what libraries should be used to implement the API design. We needed decide and figure out how the GUI will transmit control signals to the MCU and how the MCU will send status signals to the GUI; this week, we needed to figure out if we were transmitting data over USB or over UART.  Finding different libraries that we could use wasn’t difficult, but finding the best libraries specifically for the STM32 that also met our needs was more challenging.  Additionally, we needed to take into account what libraries will be use with each port and the pro’s and con’s of using various different libraries.  I went over our decision for using UART and microPython + C here.

The highest priority will be writing the code for the transactions between the GUI and the MCU; once we can successfully test and run the code, we will begin designing and creating the GUI which will be implemented in Python.

Is your progress on schedule or behind?

I believe that my progress is slightly behind; with deciding these libraries, I feel that designing the remaining parts of the project will be easier now that we know what languages and libraries we would like to use.  Plus, I can begin finding code samples and begin writing the code for the transactions between the GUI and the MCU.  However, some potential issues that may arise are issues integrating the transactions between the MCU and other components like I2C, UART etc with the transactions between the MCU and UART (GUI), an aspect of the design that I haven’t looked too much into yet.  These issues may be more apparent once sketching the functionality of the programs and writing a few programs are completed, so hopefully, this should be resolved by next week.

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

This week, I hope to work closely with my team to determine the requirements of priority for each component of our project; once the upmost important requirements are determined, I hope that we can begin designing how each of our responsible portions of the project will be integrated based on each other’s portions need.  I hope to begin writing crucial functions for the implementation to verify that it is feasible to integrate transmit and receive signals from the MCU.  Additionally, I hope to further research the usage of using UART as a port on the MCU to determine if other issues may arise to ensure that using MicroPython and UART are the best choices for our project.

API Implementation Updates

In the previous posts, we discussed the progress of our API design.  With this design, we have began researching the best ways to implement transactions between the MCU and GUI using either the USB or USART/UART port on the STM32 Microcontroller connected to the computed to display on the GUI.  So far, we have decided that the computer will receive and send data from the MCU connect the via the USART port on the MCU because:

  1. The USART port can send data via bytes serially.  With the current rough draft of our API design, the protocols on each component will be determining what error codes to send to the GUI.  These error codes will be given to the MCU, which will send it to the GUI via the USART port.
  2. The USART port can transmit data via bytes serially; by sending bytes serially, we can enumerate and send control signals to the MCU that will indicate what type of error we would like to simulate.
  3. If we do implement combinations of errors, we could enumerate the combinations of errors into error and control signals, allowing for us to simultaneously test the detecting of multiple errors.

Currently, we are deciding between implementing this in C or microPython.  Using C, it would be less of a learning curve and would be able to integrate better with our programs that we are already writing in C.  However, using microPython would be less difficult given the various built-in libraries and would allow for us to integrate easily with external C programs that we could write if the built-in functions are insufficient.  Furthermore, microPython offers libraries custom to STM32. We feel that deciding whether to use C or microPython will depend on what will integrate best with the remaining aspects of our design that still need to be determined.

To-Do:

  1. Research more into microPython and C implementations of USART and determine which one will fit best with our design.
  2. Determine how the remaining components like the communication between MCU to I2C, SPI etc. will be implemented