Most of my time this week was spent practicing for the design review presentation. I have to practice a lot in order to not feel nervous for presentations. I’m always very envious of people who can just get up and give impromptu speeches and presentations because I could never do that.
Time breakdown:
Approximately 1.5 hours was spent trying to figure out how to cut our design presentation down to 15 minutes. My early practices were around 20-25 minutes per presentation. I practiced my presentation 8+ more times to be certain that I would be able to give a smooth delivery during the actual presentation. I estimate this to take at least 2.25 hours since each presentation is 15 minutes and accounting for time to take notes between each presentation.
4 hours was spent in class. This week in class I watched and gave comments on other team’s design reviews. I’m pretty confident I gave good comments on Monday. On Wednesday, I was very nervous since I was presenting last and had a hard time concentrating on the presentations because of it and this may have impacted the quality of my comments to the Wednesday teams.
1 hour was spent in a team meeting to discuss plans to complete the design review.
The remaining time this week was spent working on writing the design review.
I am on schedule.
This week I worked on preparing for the parts and also building out a simple react app that is compatible with node-bluetooth so that we could wirelessly connect the desktop application with the Arduino. Furthermore, I started converting the figma design of the desktop application on the front end to an electron application. Currently, the biggest challenge is to learn how to write functions in javascript because I have not written too much javascript before, but I am watching tutorials on what the process is like.
This week, we worked on our design presentation and also our design documentation. We are able to finalize a lot of the metrics we are trying to use and also the algorithm.
One risk that came up this week was actually related to the Ukraine situation as our ECG sensor is being delivered from Ukraine. Currently, it shows that it has been shipped out of the country, but in case there are other issues, we will have to look into other options. Our contigency plan is to explore other potential options for ECG sensors and also potentially looking at other heart rate monitors that could be delivered from other regions.
No changes to design of system
No changes to schedule.
This week I worked on the design proposal slides and documentation. I finalized the smart contract design as well as helped with finalization of the algorithm. Moreover, I helped with the presentation and put together the testing/ verification part of the design and the use case requirements. I continued to work on Near as well and have been writing core libraries (which can be found on Github) for the smart contracts.
In terms of the design proposal doc, I put together the overall template, began filling in the introduction, and use case requirements, as well as the figures and algorithm implementation.
We are on schedule and this following week I plan on helping to finish the design doc as well as continue with the smart contracts, hopefully finishing or approaching a finish of the basic contract.
This week, I worked on the design proposal presentation, ordered different parts required for our project, did research on how to properly design a desktop application, and also researched what the best way to use a ECG is. Specifically, I ordered the ECG device which will be a key component in our sensors, along with a USB receiver base that we could potentially use such that ECG device could be connected to the body wirelessly. Furthermore, I researched into Electron App’s documentation and looked at the capabilities of Node.js to connect with our arduino via Bluetooth. I also created a mockup of our front end application, deciding which type of information is most needed for our users to see such that they feel involved in the paymodoro process. Finally, I also looked at how we could best utilize our ECG and what is the most effective way of attaching it to the body. Most ECGs are attached either to one’s fingertips or chest. However, if it were attached to fingertips, it would be very inconvenient to work and focus on other tasks. The chest is also much more difficult as the user would have to take their shirts off to put on the device. Thus, I decided to create a wrist wearable device such that the ECG monitor could simply be worn like a watch.
This week I worked on the hardware design of our system. I speced out the ECG sensor, wireless receiver for the ECG sensor, and accelerometer and placed orders for them (2 hours). I also did research into how to connect each pin of the sensors to an arduino (2 hours) to generate preliminary schematics of the system (3 hours). Getting all the wires and components arranged neatly took a very long time with my drawing software.
I also helped out with the design presentation. Specifically, the following slides:
I am on schedule. This week was devoted to specifying the entire system. I was responsible for hardware and specifications for the hardware system is complete.
As of right now, I am giving the design presentation. Thus, I will spend some time this week practicing the presentation. This next week I plan to start writing the code for the arduino to pull data off the sensors as a proof that the sensors will work for the project. If there is time left over, I will start integrating each sensor together into one big arduino program and figure out how to send the data over bluetooth to the desktop application.
This week, as a team, we looked at our scheduling and planned out the individual aspects of the project. We split up the workload amongst the three of us, and I am going to be working on the Interface and the smart contract. I started doing some research on which different blockchains would be the most beneficial for our specific purpose. I also looked into potential options of how we could create a token for the incentivization process; however, that is still an area where we have to decide whether we need to implement.
This past week I helped in creating the proposal presentation as well as presented it. I also started working out specific details of the design. I put some time into researching and learning about blockchain programming. I looked into programming on various blockchains, such as Solana, Ethereum, and Near. After, I decided that Near made the most sense as it has a low latency and simple on boarding process. I then spent 4 hours on Near University (found at https://www.near.university/) to learn Near programming and get a feel for its development processes. Our project is currently on schedule. Next week, I hope to spec out the interfaces and data structures needed for both the smart contracts and the desktop app and design the specific code structure. I also hope to start helping with preliminary mock ups of the frontend design.
The most significant risk that could jeopardize the success of our project is if the metrics we choose to monitor (heart rate variability, noise, acceleration) to determine whether the user is concentration do not actually correlate with concentration. The risks are managed by having our algorithm be easily updatable in case we need to swap out sensor measurements, (e.g. measure average eye movement instead of heart rate variability). Our contingency plan would be to vary the sensors we use.
No changes to design of system
No changes to schedule.