This week I made progress on the raspberry pi i2c code. I started by having a usable GPIO version of the pi code to demo, showing the design of the transmission protocol. Since the demos, I have made progress into using i2c. Since our PCB development is running behind, I decided to use an arduino from home as a PCB emulator until the PCB arrives. The polling rate will likely be much worse, but in the worst case we should still be able to put a product together. Furthermore, this should allow me to develop the Pi-side code enough to quickly implement once the PCB arrives.
Sherry’s status report for 11/11
This week I was out during both classes for my lab’s retreat so I did not participate in the interim demo with the rest of my group mates. I did a separate demo for my part with the profs and the TA to update them on what I have accomplished.
Aside from attending the retreat, I did more code base exploration and has successfully located where I would be connecting my code section with the API. Other than that, I wrote more code on processing the inputs from raspberry pi to incorporate the previous sliding window implementation that I completed.
I am more caught up to date with my previous planned schedule now. Next week I am hoping to finish the software system code and hopefully be able to connect my code with the API, and able to put notes on the sheet with test inputs generated from the python script.
Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?
I have written sample python scripts that will generate fake test cases that resembles inputs from the raspberry pi. I am expecting that the sample test case generated will have 100% accuracy to be translated into notes on the sheet music, as all of our errors are expected to be coming from sensor and data processing on the raspberry pi.
Team Status Report for 11/11
This week, we reached a crucial milestone by conducting and presenting our interim demo sessions on both Tuesday and Thursday. These demonstrations provided an opportunity to showcase our progress, receive constructive feedback, and refine our project’s direction. We are actively fostering collaboration through our regular group meetings, where we discuss collective project goals and address any challenges. Simultaneously, team members are dedicating focused efforts towards individual tasks, ensuring a comprehensive approach to our objectives.
Our primary focus remains aligned with our original design objectives, driving us to achieve a functional minimum viable product within the set timeline for the upcoming showcase. This overarching goal guides our daily endeavors, emphasizing the importance of meeting our milestones to ensure a successful presentation at the showcase. Overall, the team is committed to maintaining a steady rhythm of group discussions and individual work, keeping us on track to meet our project goals in a timely and efficient manner.
Jeannie’s Status Report for 11/11
This week our team worked on slides and presented for the interim demo. Olek and I also worked together on Wednesday evening to set up an Arduino to communicate over I2C with the Raspberry Pi.
This week I finalized the sensor data schematics and finished the layout of the board. I generated the gerber files and the bill of materials and uploaded them to PCBway to receive a quote which came out to around $82 not including shipping. I am currently waiting for PCBway to review the board so that I can order it. I am behind schedule, so in order to receive and debug the board in time I am planning on paying for the board to be manufactured out of house and for expedited shipping using our remaining budget.
My goals for the week are to have the PCB design approved, ordered, receive the board, and start testing it and integrating it with the Raspberry Pi for the final showcase.
ABET #6 says … An ability to develop and conduct appropriate experimentation, analyze and interpret data, and use engineering judgment to draw conclusions
Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?
Thus far, I have simulated a simple sensing circuit using the force sensing resistor sensors, potentiometers, and an LED. I tested different values for the potentiometer to ensure that the voltage output would cover the full range of the ADC. I found a value for the potentiometer that covers as much voltage range as possible whilst also illuminating the LED.
When the pressure sensor data collection board arrives, first I will test the power conversion circuitry to make sure my 5V and 3V3 rails are working. Then I’ll test that the ADC I2C chip is working correctly by ensuring the Raspberry Pi is receiving I2C packets from the PCB. Then I’ll mess around with the sensors to see if I need to change any resistance values to alter voltage levels or change my RC filter.
Max’s Status Report for 11/4
No new changes to the schedule. Have limited functionality of pitch detection and note start and stop detection on individual notes played in time. The funcitonality is stilled limited because I have not been able to extensively test the barriers of the the accuracy for both pitch detection and note start/stops. I am still currently working on polyphonic pitch and note start detection, but am planning on finishing that out this week. I am hoping to finish the have at least polyphonic note starts and stop detection by the interim demo, but if not, both are going to be functional by the end of this week.
Sherry’s status report for 11/04
I made quite descent progress on the project this week. After a lot of struggle with the code base, the dependencies and some logistics things with the new M2 chip and apple architecture, I was able to finally successfully compile the code from the MuseScore API and have it up and running on my machine locally. I also had a meeting with Olek and we discussed and came up with the architecture design of how the data is going to be transferred from the rasper Pi to the API on my machine. At the same time, I am working on writing some sample code on how to process the code from the pi into sample input into the API.
I think I have caught up a little bit in my progress. I will not be attending class next week because I will be going to pdl retreat. I wish to dig more at the code base and start connection the code with the API next week.
Jeannie’s Status Report for 11/4
Over the past week, Olek and I have been working together to test the force sensing resistors. Olek set up the Raspberri Pi and I gathered the breadboard, resistors, and LEDs to test the sensors. We were able to validate that the sensor press could be detected by running a simple script that outputs a print statement when the sensor is pressed. We also tested the response time of the Raspberry Pi returning sensor data.
Additionally, I made some last minute changes and am almost done laying out the board. It took a while to get used to using Altium and learning about board layout, but it should be done by Sunday midnight and ready to order by midday Monday. I am a couple weeks behind schedule with the PCB, but to mitigate this issue I am planning on using our leftover budget to expedite the manufacturing and shipping of the PCB itself and accompanying components.
My goals for this week are to finish the layout this weekend, order the board, receive it, and get it reflowed. I want to have it finished and be ready to test by midway through the following week.
Team Status Report for 11/4
Team Status Report for 10/28
Over the course of these past few weeks, one of our team members has had some personal matters come up that have interfered with his ability to participate in the project. Previously, we had moved forward with a slightly modified implementation plan that would mean leaving their portion out, allowing for the rest of the group to finish out their parts in an effort to still have a final project to show at the end of the semester. This final implementation plan is more concerned with what we will leave out of our project, and is still very generic in our head as we want to keep our project as close to its original proposal as possible, so we are planning on reevaluating our scope each week in order to make sure we are able to get the project done but still achieve as much as we can. This past week, the missing teammate was able to come back into the fold, but due to the rest of the group’s busy schedules, we are having our full team talk and rescoping this upcoming week. In terms of updates on changes in design, all of our previous changes have stayed, and any changes to schedule as a full group have yet to be discussed with the full group, but will be within the next few days.
Sherry’s status report for 10/28
This week I focused mostly on evaluate the ethic concerns about our projects. I brainstormed some possible scenarios where our projects can be used with malicious intent and how to prevent these situations from happening. I also evaluated the idea of using different components in our design to potentially eliminate the potential harm.
Other than the ethics component, I looked at some official documents of how the API is being composed and set up. I also looked at some part of the API source code but has not finished looking at everything yet.
I made descent progress this week, but a lot more needs to be done with regards to the software API component. Next week I plan to continue the work with the API and move on to see how additional code can fit with the API.