Status Report – Page 4 – Project Belka

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

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

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.

Mia Han’s Status Report for 2/22/20

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

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.