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.

 

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

 

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.

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

What did you personally accomplish this week on the project?

This week I focused on finalizing the User Datagram Protocol (UDP) that we will be using for communication over Wifi. I was able to settle on a simplified version of the Transmission Control Protocol (TCP). Using some code I had written previously I was able to write a very basic python program to mimic the protocol I decided to design.

Some of these decisions that were made are outlined here.

I also spent a lot of time meeting with my team in order to finalize the APIs. We also spent a lot of time making general design decisions concerning the layout of our system.

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

My progress now seems to be on schedule again. Looking on the Gantt Chart I am right on schedule in terms of the design and I was hoping to get ahead on the implementation of the UDP protocol over WiFi. Even though I haven’t started the final implementation of this protocol on the MCU, I was able to write a preliminary test protocol that will be very useful down the road when implementing this protocol.

Looking forward into next week, a lot of my time will be put into creating the final design doc for the project. I think this will end up putting me a little bit behind schedule so I might have to do some overtime next weekend in order to stay caught up on the implementation stage. I feel that getting a prototype done early will be huge for the parts that I am working on as I’m guessing that optimization will be the most time intensive part.

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

Next week I will be focusing on getting the design document finalized and completed. This will include the consideration of any criticism that we received during the design presentation.

I also want to start playing around with the MCUs that were shipped in this week to see if we can get some basic communication going.

Sam Adams’s Status Report 2/15/2020

What did you personally accomplish this week on the project?

This week I mainly focused on defining the parameters for the UDP protocol. I had already decided to write a TCP implementation over UDP but I used this week to look deeper into the specifics of the protocol. I looked through some libraries that others had written to see they satisfied what I was looking for, but I determined that the best approach would be for me to write my own protocol from scratch to allow for maximum customization and optimization. In order to write this protocol from scratch I spent a lot of time reviewing my code and notes from 18-447 (Introduction to Computer Networks) where I worked on very similar protocols that I will be implementing later. This took up a majority of my time.

The second thing I worked on this week was researching the software structure of the drivers. I was able to find the source code for drivers running on both the Hercules RM36 MCU and the Watchdog MSP430FR5994. This allowed me to start planning how we were going to implement the serial protocols (especially i2c).

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

I hoped I would have been able to define all of the parameters for the TCP over UDP but I wasn’t able to fully do that. In order to catch up I hope to spend some time before our team meets in lab on Monday to fully define the UDP protocol.

I had hoped to start implementation of the i2c drivers this week. Even though that did not happen I believe that we made significant enough progress to get some real work done next week as I was able to define a starting point for the implementation of the serial communication protocols.

Even though I am not as far along as I’d hoped to be, I am a lot more confident going forward. Coming into this week I was very lost on what I should be doing to accomplish our goals but after this week I feel much better about things going forward.

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

Next week I hope to be able to write an initial testing routine along with a basic UDP protocol. I also hope to be able to start creating a simple test for the i2c driver protocol on both the Hercules and the Watchdog. I believe that establishing these workspaces for both the UDP and the i2c protocol will be paramount to our success in the future.

API Rough Draft Overview

We have partitioned our API into two parts of control and status. Since our current plan is to implement our GUI and Microcontroller to run micro-python, the API examples will be in Python3.

Control from GUI:

We are defining two different ways to control from the GUI, either by bits or by packets. API sketch below:

 

Status from MCU:

We are sending status to the computer only in one command, which is sendStatus. API sketch below:

Team Update for 2/15/2020

What are the most significant risks that could jeopardize the success of the project?
Our biggest risk currently is getting our specific requirements down for what goal we want to accomplish.

We want to be able to create an interesting problem while still meeting the project specs of CubeRover, so we’ve decided to add more rigorous measures that will expand on the current protocols. For instance, in order for Turbo Coding to be truly effective, we must send large data such that our added computation is worth the clock cycles to run.

Another risk that could jeopardize the success of the project is the learning curve for understanding and implementing complex error detection and handling algorithms that all of us are somewhat experienced and familiar.  All of us have some experience implementing error detecting and correcting algorithms for data transmission, but to achieve our goal of finding and writing the best algorithms for what we want to achieve, we may be spending an unexpected and  greater amount of time implementing such algorithms.

How are these risks being managed? What contingency plans are ready?

The risks are being managed by circumventing most of our outside influence. We are planning to take the essential functions asked to be delivered by CubeRover without only working within the scope of their project. Our contingency plan is that if we do not get all necessary documentation to implement along with their specifications, then we will make the decisions ourselves on what to implement, keeping their core instructions intact. For instance, if we are unsure of whether we need to implement a small number of data packets being sent or a large number, they have different trade-offs depending on implementation, so our goal is to implement a valid solution and verification for both so that we don’t have to spend any time waiting for communication between teams.

The risks will be managed by recognizing when the implementation of certain algorithms may be too difficult and unfit to implement for our project and begin slowing down the progress of the project.  If we find ourselves in this situation, the contingency plan will be implementing another algorithm that will successfully error detect the effects but won’t be ultimately optimized to meet the constraints of the project; actually writing the algorithms and verifying that error detecting and handling is successful is upmost priority, and then, we can begin figuring out how to optimize the program given a working program.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?

There were changing made to the existing design because we added a different way to interface with our Microcontroller from our Computers which will be UART or USART.

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 the current USB slot is being used for loading the program onto the microcontroller, it also adds ease of use to interface through UART.

Provide an updated schedule if changes have occurred.

Our updated Gantt Chart parallelizes the work that we are doing so that we have more time to work on individual responsibilities while still being on schedule.

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.

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

A lot of the work I did this week was formally putting our meeting work together into a digestible format. I also did more thorough research on what specific error correction code we were going to use since there are multiple benefits and drawbacks to each. LPDC was our frontrunner in the beginning, but we are now shifting towards Turbo Codes since it has become the space pseudo-standard.

You can check out my formal proposal for such a use here.

I also went ahead and re-verified the parts we were using before our plan of purchasing in which I added a new, necessary peripheral in order to act with our microcontroller, which is a USB to TTL connection to help interface with the SMT Microcontroller via UART.

Our group collaborated on what our overall structure is going to be, but I formalized it here.

Our group collaborated on what our overall API is going to be, but I formalized it and reformatted to a more UART-centric format here.

The Turbo code formatting is not well-documented on it’s implementation so that is where the majority of my week went into. Figuring out how exactly to implement this ourselves and deciding whether this will be a viable solution in the long run.

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

According to our initial Gantt chart, we are behind on our progress. We are planning to do order our parts as soon as possible which will allow us to begin our deployment onto each component. The other is while we are waiting for our parts to ship, we hope to do a pre-simulation without outside peripherals which will only be functions running within the command line. We have allowed ourselves a little slack since we initially planned for a sequential implementation instead of parallel, but I would personally like to be much further along in the project.

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

My deliverable for the next week is to submit the order forms for all the necessary parts. Then start with a base implementation of I2C that will allow passing of data frames between two instances running. Then be able to add error insertion into the protocol through a middleman instance, which will finally be able to detect error. I’m limiting just to error detection for now so that we can establish our upper-bound of our error correction, which is just asking to send the packet again.