The most significant risk for the project is still the sensing of which string was strummed. We are confident in our ability to detect strumming, but which string is a much greater challenge. We have been brainstorming solutions to this issue, including using a capacitive touch sensor on each string to sense when the user touches them. The main issue with this approach is that it would falsely report values if the user was resting their fingers on strings other than the one being strummed. Additionally, the sensors are often slow to react and would not work well with the strings being driven to 0 and 3.3V. We have also thought about using inductive pickups under the strings. The main challenge with this solution so far has been finding pickups that individually sense each string instead of combining the signals together. To mitigate risks, we have come up with a solution that will work but is slightly more intrusive for the user. This solution would involve applying a voltage to a metal guitar pick. This would occur when all the D-flip-flops are outputting low, so if the pick contacted a string, the string would be brought from 0V to 3.3V. This would allow us to detect where the pic is. Combining this with the strum detection, this will allow us to determine when the user strums and what string is strummed.
Design Presentation block diagram:
The most significant change made to our design presentation block diagram is that some of the MIDI parsing will likely be switched to the Teensy. This is because the note and timing data needs to be sent to the Teensy somehow, and it will be easier to do this using an existing format rather than making our own method of conveying this information. The Pi will potentially also be performing some MIDI parsing in order to display to the user things like where they are in a song, what notes they are getting wrong, etc., but the raw MIDI file will also be sent to the Teensy. Since Ashwin is becoming more confident with Django and HTML/CSS, we are expanding the webapp to include visuals indicating the user’s performance, such as if they are incorrectly timing notes, what percentage of notes they fingered correctly, etc.
The most significant change in the schedule is that the assembly and testing of the PCBs for the fretboard will not be able to start until likely Monday since the shipping was delayed slightly. Ideally by Tuesday at least one of the boards will be ready so that Tushaar can help test it. Progress on the UART communication between the Teensy and Pi, along with the interrupts, is ahead of schedule, which should hopefully allow for the user interface and experience to receive additional attention at the end of the semester.
Overall team progress consists of Ashwin being able to send MIDI files to the Teensy with the press of a button on the web app. There is occasionally some loss during this transfer so we need to determine the cause of this. Tushaar is able to light up LEDs in response to a MIDI file on a set of RGB LEDs, and this will hopefully be able to be tested on the fretboard PCBs when Owen gets them assembled. The guitar should be in by Monday so we expect to be able to verify the strum detection concept and the sizing of the PCBs very soon.
The main goals for this week are to continue working on the UART communication between the Pi and Teensy, establish more of the interrupts used to control the Teensy, and for Owen to work on a PCB that will connect the Teensy, Pi, and I/O in accordance with the needs of Tushaar and Ashwin.
Weekly Status Report Question:
While developing a more detailed plan of our implementation for the design presentation, our team used numerous principles of science, engineering, and mathematics. While developing plans for our individual components of the project, it was important to keep the principle of integration in mind. While we each have an area of expertise on the project, each of our systems will be interacting with each other’s. For example, the fretboard PCB board PCBs need to be able to interact with the 3.3V logic level of the Teensy, which will allow for the firmware on the Teensy to control the LEDs and read from the fretboard. Similarly, the firmware on the Teensy will be playing the songs, but in order to do this, it needs the actual data for the songs to be sent by the Pi. Similarly, the Pi will be displaying statistics on the webapp, but in order to do this, it needs to be able to receive and interpret the data sent by the Teensy. As a result of these factors, it has been absolutely essential that our team is in constant communication regarding design choices and intentions. Otherwise, when we go to assemble our final product, the systems will not be able to interact with each other properly. Our weekly meetings allow us to take what we have been working on independently, explain it to each other, and work on integrating the systems together. This week, we were able to take Ashwin’s web app interface to send interrupts to the Teensy, which Tushaar was able to read and react to. We were also able to test and debug the UART communication between the Pi and Teensy.
Another principle that we used extensively this week was management. In order to ensure the smooth completion of the project, it is essential that everyone knows what tasks they are responsible for, when/how it will be completed, and how it will affect them. This involves constant communication between team members to ensure that everyone is on the same page. Our weekly meetings help us to recap with each other how progress is going so we can verify that tasks are being completed. They also allow us to talk through any potential modifications that need to be made to our plans/tasks for the future. This allows us to be confident that we will be able to successfully navigate around any unexpected challenges or setbacks and end the semester with a completed project.