Category: Team Status Reports

Unit testing throughout semester:

Strum Detection Testing:
In order to detect strums, we initially planned to use an audio-based approach. However, after Owen assembled the system and tested it, he found that the system was quite slow to respond, had an accuracy well below the 99% target, and was too sensitive to external noise. We found that for a beginner that will accidentally strike strings while moving their fingers or cause strings to chatter while playing, this method of detection would pick up on these noises and trigger a false positive strum.
We created a pick with an electrode and found that this method was far more accurate and was less intrusive than we originally thought, so we pursued this method.

Fretboard PCB Testing:
The fretboard PCBs were tested using a RPi Pico hooked up to a perfboard, as shown below.

The Pico would provide the D-flip-flop various inputs and would analyze the output of the D-flip-flop. These inputs included things such as having the inputs rise at the same time, rising with varying delays, etc. The results of the tests were outputted on the LEDs on the PCB, where a green indicated a pass on all tests. This unit testing discovered a soldering flaw on one of the fretboard PCBs

Once soldered together the flip flops were tested by providing a signal that would shift a single “1” down the line of flip flops and probing the output of each flip flop using an oscilloscope. This revealed an issue with our first revision of PCBs, which we believe was due to timing violations caused by propagation time along the connecting wires.  To resolve this, an RC lowpass was added between the output of each flop and the input to the next flop. This served the purpose of delaying the data line signal by around 1us with respect to the clock line. The second revision of PCBs had no issue with this test. The maximum short circuit current from the fret connection to ground was also tested and verified to be below 1mA, allowing us to be confident we would come in under the 1mA current requirement.

Pi Hat PCB Testing:
The Pi Hat was tested using various lab bench tools before ever connecting it to the Teensy or Pi. This consisted of connecting the 5V input to a lab bench power supply and measuring the voltage on the power pins for both the Pi and the Teensy. An E-load was used to draw the maximum expected current from each power pin as well to ensure the power distribution was functional. The logic level conversion was tested by connecting the Teensy, outputting a signal, and using an oscilloscope to measure the input and output to the converter. As expected, the waveforms looked identical other than the voltage being converted from 3.3V to 5V.

“Virtual” Guitar Testing:
While the final product has the virtual guitar synced to the user’s playing on the physical guitar, work on the virtual guitar was started well before the web app was communicating with the firmware/hardware. In order to do this, Ashwin implemented a “simulate strum” button on the web app which allowed for him to test the functionality of the virtual guitar without interacting with hardware at all. When we were ready to integrate the system with the hardware, we simply had to replace the simulate strum button with the signal sent from the Teensy. This made integration fairly straightforward.

Firmware Testing:

Since the full assembly of the guitar was not completed until later in the semester, Tushaar needed to be able to test his systems on other hardware. Within the first week of work, we were able to secure both a Teensy and WS2812 LEDs. This allowed Tushaar to test the functionality of the NeoPixel library for the Teensy, the function of the state machine using interrupts attached to pins, etc. With slight modifications to fix the issues with the Rev 1 fretboard PCBs, Tushaar was also able to test running MIDI files on a set of 5 fretboard PCBs and test the functionality of the finger placement sensing using a mini practice fretboard.

The first thing tested was the functionality of all fretboard finger placement sensors and LEDs. I did this by using Tushaar’s functions and writing some firmware to light up the LED under where the user is pressing. With this in place, I tested each of the 56 possible finger placements 5 times each, and the corresponding LED lit up each time the sensor was tested. This has also been continuously tested as we have been testing various songs on the guitar during integration testing. This means that the control of the LEDs and the reading of the finger placement is 100% accurate.

Firmware-Software Integration Testing:
The communication between the firmware and software consists of UART in each direction and a series of interrupts sent from the Pi to the Teensy on GPIO lines. We tested both forms of communication from the Pi to the Teensy fairly early in the semester by sending a MIDI file and verifying the byte count sent and received. Tushaar was also able to use the interrupts sent by the Pi to control the state machine. With this tested, the firmware and software were developed independently and were able to be easily integrated later in the semester.

Assembled Fretboard Testing:
After attaching all the fretboard PCBs to the guitar, Owen used a RPi Pico to control the fretboard LEDs. This allowed us to verify the functionality of all the LEDs on the system. Owen also once again used an RPi to send a series of signals to the D-flip-flops and used an oscilloscope to verify that each fret was driven high at the proper time.

System Testing

More details on system testing can be found in Owen’s report for 12/2/2023.

Current Through User:

Our requirements state that this must be below 1mA, which is why we implemented a 3.3kOhm series resistor for each fret. Testing was performed with a lab-bench ammeter capable of 0.01uA precision. The average short circuit (assuming the user is a 0 Ohm short) was 5.37uA. This dropped to approximately 0.80uA when put through various individuals. This is over 1000-fold below our target average current, so this test was a success. Average current is so low because the fret sensors are only sampled for a handful of microseconds, and the full firmware loop is on the order of milliseconds. A 47Ohm series shunt resistor and an oscilloscope were used to measure the peak short circuit current as 0.762mA, which lasts for 10us. This is ensured to be below 1mA by the series 3.3kOhm resistor and by a ~0.5V voltage drop on a diode.

By modifying Tushaar’s firmware with code to time the main loop, we were able to find that the system’s main loop time was 1555+-10us for both system modes (training & performance). This loop time directly corresponds to an LED refresh rate of 1555us, or 640Hz.

Strum to LED update delay was determined using an oscilloscope set to trigger on a strum. This was done by probing the string the pick struck (while the pick was at ~3.3V minus a diode drop) and triggering on a falling edge, meaning the pick has left the string. Owen then probed the LED data line and determined that there is a 1850us delay between the strum and when the final LED on the fretboard receives its data.

Current consumption was measured for each component. The results were:
Pi: 0.45A
Teensy + Fretboard flip flops: 0.12A
LED current at 1/2 brightness rainbow*: 0.39A

We found that the Pi drew far less current than we planned for, meaning the LEDs are able to be run at maximum brightness if desired. However, we found that maximum brightness was too bright for most users.

Strum rate was tested by strumming each string 200 times to the beat of a metronome and using the Teensy to count strums. I was able to strum up to 300BPM before strums began to be dropped (requirement was 200)

Buzzer audio level was 75 dB at the average user position

System battery life was tested while we were performing debugging of the web app (all systems were verified to be drawing nominal current despite the work occurring on the webapp). We found we were able to achieve around 3.5 hours of battery life without overdischarging the battery.

One thing discovered during this test was that after around 40 minutes, the firmware would begin acting strange. Owen and Tushaar were able to identify the issue as an overflow of the micros() function. Tushaar was able to resolve this issue by switching to the millis() function for determining note timing, which still provides more than enough timing accuracy.

User Testing:
In order to verify that we were meeting use case requirements, we tested the system on a handful of people with no guitar experience. We had the users play “Twinkle Twinkle Little Star” a handful of times. After interacting with the system, the users were provided with the following questions:

Questions:	Points (1-10)
How intuitive is the interface?	8.5
How responsive is the website?	10
How aesthitecially appealing is the website?	7
How unintrusive are the guitar modifications?	10
How visible are the LEDs?	10
Responsive is the guitar?	9
How cohesive is the entire experience?	10

The average values reported by the 5 testers so far are also shown. Overall the feedback was very positive and all the user testers felt the LEDs were effectively able to guide them in the playing of songs. We plan to continue user testing throughout this week.

Weekly Update

There are no risks jeopardizing the project. We have removed the scales feature from our target goals. While this likely would not have been difficult to integrate, we believe that the current system provides more than enough functionality for a beginner to get started with playing songs. No changes have occurred to the team schedule.

The main work this week was on fixing some minor issues with the web interface and adding statistics to the web app. We also added volume control for the metronome via the web app and worked on uploading numerous songs to the web app for demoing.

Most work this week was focused on the final presentation, poster, and prep for the demo.

Currently, the project is in decent shape. No significant risks are jeopardizing the project. The main tasks left are displaying the statistics and making the system slightly more user-friendly and less buggy

No changes have been made to the overall system block diagram and the main progress this week has been finalizing some integration and adding minor features. Owen chose to rephrase the strum rate requirement to be “200 strums / minute” instead of “100BPM 1/8th notes” for clarity, but the required value did not change. We also slightly changed the LED current requirement from being at 1/2 brightness white to 1/2 brightness for the standard color on each string. We color-code the strings rather than setting them to white, so this is a more meaningful requirement

The main team progress this week was working on the communication between the Teensy and the Pi. Pi to Teensy communication has been in place for a while, but the communication from the Teensy to the Pi, and then to the web app, proved to be more complex. Tushaar implemented the UART communication on the Teensy side, and Ashwin implemented the communication from the Pi to the webapp. Owen and Ashwin worked together to read in the UART data on the Pi. This took quite a while to make work consistently, but the communication is now reliable and quite rapid.

The data sent back consists of a single integer, which contains whether the user played the note correctly or not and how incorrect their timing was. This information can be used to update the webapp graphic and will eventually be used to provide statistics as well.

A video of the communication to the webapp in action can be seen here: https://youtu.be/G2P06dhhFrA 

We also finally implemented the communication of the system state from the Pi to the Teensy. Previously, the system had to be switched between “performance” and “training” mode by modifying the firmware on the Teensy. We have now implemented a selection on the webapp for the mode. This data is included in the UART communication to the Teensy. The Teensy then uses this information to set the mode.

Finally, we worked on implementing the buzzer/metronome, which was the final major system requirement that we had not started on at all. This turned out to be relatively quick on the firmware end and was not too difficult to implement on the Pi. The Pi uses the MIDI file to find the song tempo and sends this info to the Teensy, which then sets the buzzer to this tempo.

No changes in the schedule have been made. As indicated on our schedule, we are mainly working on integration and the final project documents. We have also been maintaining a list of bugs/to-dos in addition to the Gantt chart that helps us quickly sort in-progress tasks and take care of them

Currently the main tasks remaining are fixing minor bugs and working on the final presentation, video, and report, as well as prepping for the demo

The biggest risk that we are currently facing is the ambiguity over the time synchronization between the website and the guitar. Since both of them are displaying to the user the song at the same time, it is crucial to have them synced up to a reasonable amount. Thankfully, based on early testing, the delay between when the website inputs a query and when the backend receives the query over local wifi is small enough for the user to not notice. However, if the wifi gets slow and causes the connection delay to increase, then it is possible that the website could become completely detached from the guitar during the song. So we decided that the guitar timing information will be calculated on the teensy itself instead of sending pulses to the webpage so that at least the statistics will be correct for the users playing even if the website is delayed.

Progress is also on schedule with the Gantt charts presented during our Interim Demo.

The most significant risk currently facing the project is the carving of channels into the fretboard. This is proving to be more difficult than initially expected. Owen is working with experienced machinists at Roboclub to determine the best way to accomplish this. We have a backup plan of carving the channels with a Dremel, although the quality of this will likely not be ideal due to the angle we will have to use the Dremel at.

No changes have been made to the system block diagram. Progress on software and firmware is going well and the electronics hardware is complete other than final assembly and testing.

Progress is also on schedule with the Gantt charts presented during our Interim Demo.

The main team progress this week was the testing of the Pi controlling the Teensy state machine via interrupts. This was done using the Pi-hat PCB, allowing us to confirm that the PCB allows for communication between the two boards and properly distributes power to both boards. Tushaar and Ashwin have continued their discussions regarding communication between the boards, such as the preprocessing of the MIDI file done on the Pi and the format in which statistics will be sent back to the Pi from the Teensy.

Team progress for this coming week will be the connecting of the new fretboard PCBs to the Pi Hat for testing of the LED control and D-flip-flop control. Further work on and testing of the Teensy-Pi communication will be performed as well, particularly on the UART communication of the song data from the Pi to the Teensy and the statistics reporting sent from the Teensy to the Pi.

This past week, we resolved a severe issue with the fret detection. This allowed us to integrate and verify fret detection from a software and hardware perspective. The pi hat PCB also arrived and was populated with components. The web interface was significantly improved with a visual indicator of the song.  We also discussed priorities moving forward, especially on the web app front, and gearing up for the early demo next week. On the embedded side, fret and strum detection code were written and verified, and a first pass at the user experience (training mode) was written.

The following picture shows the Teensy4.0 and RPi connected via the Pi-Hat PCB that came in earlier this week.

The following picture shows the electronics in a 3d-printed housing:

This image shows the latest concept for what the web app will display while the user experience is running:

This image shows we can detect the fret that the user pressed on (the corresponding LED lights up)

 

As for priorities, we have determined that everyone shift focus towards integrating their parts with everything else because we are at the point where many of our tasks span more than a single person’s expertise. We have also determined that adding scrolling notes to the web UI is not a top priority since it is merely a visual add-on, and other core functionality still needs to be implemented, such as implementing the rest of the GPIO signals on the RPI.

 

 

 

 

 

Currently, the most significant risk to the project is the functionality of the fretboard PCBs used for finger placement sensing. The issue is that the D-flip-flop shift register is not working as expected and as such, the finger placement sensors are not functioning. Tushaar and Owen have spent around 6 hours working together to resolve the issue, along with Owen working to solder new boards and resolder the existing ones to little avail. Owen believes that he may have a fix for it, but if not, we have a contingency plan for running individual wires to each fret. While not ideal, this approach is simpler and less error-prone. The Pi Hat PCB has been designed with enough GPIO pins that will be feasible. Since the fretboard PCBs have been delayed due to this, we may use some budget to have shipping on them expedited in to ensure that we have sufficient time for assembly of the system.

The main change to the system block diagram is that we are planning on shifting the strum detection from an audio-based system to detecting the electrical contact between the pick and the string. This addresses the previous issue of being able to detect which string is strummed and increases the accuracy of the strum detection system by reducing false-positive detection of strums. This will also reduce the complexity of the system by enabling the firmware to not handle the strumming as an interrupt, but rather read it in during the system’s main loop.

In terms of schedule changes, the main change is that Tushaar and Owen are slightly delayed by the issues with the fretboard finger sensing. The cutoff time for switching to the contingency plan of class time on Monday will enable us to stay on track though, especially considering the contingency plan is easy to execute both in hardware and firmware.

The main progress this week was Owen ordering the Pi Hat board, Ashwin making progress on the web interface displaying notes, and Tushaar making progress on the Teensy state machine.

The most significant risks we are facing with our project are still detecting which string is strummed and also indicating to the user how long to play a note/when the next note is coming.

The solution we currently plan to implement for determining which string is strummed is to put a metal contact on the guitar pick and detect when it is in contact with one of the strings the same way the finger placement is detected. Owen has constructed some guitar picks with metal tips that we can test out for this purpose, as shown below

For the other main risk, we currently have plans to indicate the tempo to the user, but songs have rests and notes that last more than 1 beat, so we need an indication to users regarding when to play a note. One potential solution to this is to have a set of LEDs on the fretboard not dedicated to showing you where to place your fingers, but showing you when to play the next note in the song.

The main change to the system block diagram has been that the Pi-Hat PCB will no longer contain the strum-detection circuitry, and this will instead be done on a perfboard. This will enable more flexibility and modification to the circuit in the future and reduces the risk of an issue affecting the circuit. The strum detection circuitry will interact with the Teensy via pads on the Pi-Hat

There have been no changes in the schedule and progress is on track.

The main team accomplishments this week consisted of Owen assembling the fretboard PCBs, which Tushaar was then able to control and light up to the rhythm of Twinkle Twinkle Little Star. The rhythm was determined by a MIDI file, which Tushaar and Ashwin are able to communicate between the Pi and Teensy. This week, we hope to test the finger placement sensing and perform further integration of the Pi and Teensy communication.

This image shows 3 of the 5 assembled fretboard PCBs being controlled by a microcontroller to light up in a pattern.

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.

The most significant risks that we are currently dealing with are the detection of which string is strummed and that the same note can be played with different fingerings.

We currently have a plan regarding how to detect the user strumming, although we do not have a method yet to determine which string was strummed. We have been brainstorming various methods to do this, all of which have potential. The first is performing capacitive touch sensing of the strings. This may be difficult though since the user may rest their fingers on the strings other than the one they are strumming. Additionally, the strings are already being driven by other signals so we would have to perform some sort of multiplexing on the strings to do this. We have also considered using COTS inductive pickups, although we have yet to find one that has an individual output for each string, which we need. One final method is to use a separate microcontroller with the sole purpose of sampling audio, performing an FFT, and sending this to the Teensy. The Teensy loop is likely going to be on the order of 100Hz, which means it cannot sample audio fast enough.

Regarding determining which finger placement to use, our current plan is to determine the physical distance between the previous note and the various finger positions for the next note, and choose the closest. This will involve creating a simple distance metric that the Teensy can run.

No major changes have been made to the system block diagram or implementation. One minor change is that we originally planned on using a 12V power supply along with a 5V buck converter. This would enable plugging in a 3S LiPo battery for mobile use. This was done to remove the need for a 5V 5A buck converter. In the future, if we would like to use a battery, we can simply add a buck converter with a battery connector on one side and a 5V barrel plug on the other side.

No changes to the schedule have been made

This week’s accomplishments:

• Tushaar developed a state machine for the Teensy and decoded a MIDI file. He also has been able to run the NeoPixel library on the Teensy and control a series of 16 LEDs
• Ashwin set up the RPi with Django and has hosted the webapp from it. The webapp currently has the ability to upload MIDI files and delete them. The Pi has been setup so it can be easily accessed via a2superfret.wifi.local.cmu.edu.
• Owen has finished the design of the fretboard PCB and sent it out for fabrication. He has also created a circuit that can do strum detection with a fairly high accuracy, although this will need to be tested on the actual guitar
• As a team, we ordered the guitar and discussed exactly what data and signals we want to send between the microcontroller and Pi
  

This coming week we hope to verify certain aspects of the guitar, such as the continuity of the guitar strings, the string spacing and fret spacing, and analyze the audio picked up by a microphone in the guitar. As a team, we hope to further refine the signals sent between the Pi and Teensy. We also hope to assemble the PCBs if they arrive so that we can begin writing to the LEDs on the boards and writing code to read from the frets.

 

One of the primary concerns brought up regarding the SuperFret project is that the metal frets of the guitar will be driven to 3.3V. When the string contacts the frets of the guitar, they will be driven to 3.3V as well. Since the user will be in contact with the guitar strings, concern has been raised regarding the system’s potential safety hazards. Fully understanding any safety concerns with our project is our number one priority, since as developers of a product, we have no right to put users in the way of any degree of risk. Users of the system may be unfamiliar with regulations and standards regarding safe voltage and current levels, so it is our job as designers to ensure that all safety considerations have been addressed.

Before ever selecting our project topic, we fully considered the risks to the user and determined that they were non-existent. In the time since selecting our project, we have further researched this topic to confirm the conclusion that putting 3.3V on the strings poses no safety risk.

According to  IEC 61140:2016, Extra-Low Voltage is defined as less than 50V RMS for AC signals and less than 120V for DC signals. The IEC defines Extra-Low Voltage signals as having a low risk of electrical shock. The IEC further defines the Safety/Separated Extra-Low Voltage classification, which is used for voltages so low that even in the event of a system fault, there is no risk of electrical shock. To fall into the SELV category, systems must not expose users to voltages of 60VDC or higher for more than 200ms. Our intended solution for applying voltages to each fret will consist of pulses of 3.3V measured on the order of tens of microseconds, meaning our system would fall into the SELV classification.

Additionally, OSHA 1910.303(g)(2)(i) states that voltages above 50V are to be considered hazardous, with very rare reports of burns resulting from 12-24V car batteries. All incidents reported by OSHA 1910.303(g)(2)(i) at these voltages resulted from the voltage source coming into contact with a ring or watch worn by the user, and were at voltages 3-4x what we will be using. As such, we are confident that by requiring users to not wear any metal watches, rings, or bracelets, there is no risk of shock with our system.

For our proposal, we required that in dry conditions, our system falls within the IEC TS 60479-1 AC-1 classification, which defines a signal that is imperceptible to humans. This requires a current under 0.5mA to flow through the body. Dry skin typically has a resistance of at least 50kΩ, although assuming a worst-case scenario of 10kΩ, this will correspond to a current of 0.33mA flowing through the body. In wet and/or sweaty conditions, we will require that our system adheres to the IEC TS 60479-1 AC-2 classification, for which signals are perceptible but do not affect muscles. This classification requires under 5mA of current for continuous signals, although we will limit our system to 1mA worst case. To do this, we will put a 3.3kΩ resistor before the 3.3V signal connects to the fret, meaning that no more than 1mA can flow through even a direct short circuit. By doing this, we are confident that our system will pose no risk to safety.

Other factors that we considered were environmental and economic. By requiring permanent modifications to the guitar to be made to install our system, we must not unnecessarily increase the waste of resources or money. This was one of the many considerations that led to our requirement that the guitar should still feel and play normally when the system is not in use. Although the system will modify the guitar, the normal functionality will not be affected, and therefore if the user does not want to use the system, there is no need to purchase another guitar. While a removable system using a flexible PCB that spans the entire fretboard may be possible, to reduce excessive design risks, we decided to steer away from this option in favor of smaller modular PCBs spanning the guitar.

In addition to working on our project proposal presentation and trying to consider as many aspects of our project as possible, this week we worked on acquiring a Raspberry Pi from the ECE supplies and researching guitars. We were worried about picking up strumming from ambient noise, but in our research, we learned that many electro-acoustic guitars use piezoelectric pickups at the base of the strings to directly measure the vibrations of the strings. Getting a guitar with this system and tapping into the output of the piezoelectric sensor will likely provide us with a signal that is significantly more resistant to external sounds and movements. We hope to finalize our decision this weekend on a guitar so we can progress further with preliminary testing and implementation.