Don't Fret

Overview

For many guitarists, when they go on tour or play a multiple song set require various effects to effectively perform. For instance a set played in Chicago may need a pedal that is more oriented towards blues music that includes distortion or overdrive as opposed to a set played in Nashville may require a compressor. This means that a guitarist may have to take a handful of pedals that have a high per unit cost.

The concept of our solution solves this issue. We need to design a pedal that can handle multiple effects for when multiple effects are called for in one set and also a pedal that can reprogrammed easily so if the set changes day by day a guitarist can adapt. This solution will reduce the amount of pedals that a guitarist has to carry and will also greatly reduce the cost as the guitarist will only need one pedal that can handle absolutely any effect where one single pedal can cost anywhere between $25-$1000.

The goal of this project is to create a device that takes a sound input, specifically from a guitar, and outputs a manipulated sound. The device will utilize a Raspberry Pi to take the input from an instrument and return an edited sound. The coding will most likely be done in C and allows for a unique effects from the standard reverb, fuzz, etc. effects as well as extensive capability to reprogram.

Work Log

Link to Log: https://classes.engineering.wustl.edu/ese205/core/index.php?title=Don%27t_Fret_Log

Team Members

• Chance Bayles
• GraceAnne Aldred
• Jared Malkin
• TA: John Fordice
• Instructor: Jim Feher

Objectives

• Learn to utilize Raspberry Pi (basics)
• Adapt code from https://www.electrosmash.com/pedal-pi and https://blog.hackster.io/program-your-own-guitar-effects-with-pedal-pi-d77b8c56c0b0 to allow the pedal to run two effects
• Adapt circuitry from the single function pedal on https://www.electrosmash.com/pedal-pi to account for an additional pushbutton to trigger second effect
• Learn how to 3D print a cover and design a cover that allows for usage of both pushbuttons
• Assemble together as a unit and test with guitar and amplifier

Challenges

• Learn to program a Raspberry Pi
• Allowing Raspberry Pi to take input (instrument) and give output (amplifier or microphone)
• Putting together circuitry to add a second function
• Coding for a second function

Materials

Supplied

• Raspberry Pi 3
• Assorted Capacitors and Resistors
• 3mm LEDs

Purchased

• Resistor Trimmer $0.38

• Op-amp rail-to-rail, pdip8 $0.40**

• 12bit ADC, p-dip8 $3.47**

• socket dor dip8 $0.10 x2

• 3PDT footswitch $7.73

• SPDT toogle switch $2.11

• off-on pushbutton $1.01 x2

• stereo 6.35mm jack $2.01 x5

• Plastic Case $7.44

(Total Shipping Cost)

• $43.46

TOTAL: $80.49

Ghant Chart

Project Proposal Presentation

• 
• 
• 
• 
• 
• 

Design and Solutions

Ideation and Acquisition

After preliminary research, we came across a project that had been worked on by the open source British electronics group Electrosmash. The project can be found here, Electrosmash. This project gave us the basis for the design project we embarked on. Electrosmash used a Raspberry Pi to great a single effect pedal. The project would provide us with the basic circuitry we would use to create our pedal and also would provide the baseline for the code used by the Pi to create the effect.

To improve upon this previous project we knew that we would change the configuration of switches to easily change between two effects and we would adapt the code to allow for multiple effects to be ran and easily changed. A case had to also be designed that provides enough support to be stomped on multiple times as a guitarist would over the course of a tour.

This defined what we had to build so we identified parts that were needed, covered above in materials, and purchased them off of Mouser Electronics, an online distributor of electronic components.

Building the Circuit

Based off of the circuit diagrams found at here, we built a preliminary version of the pedal circuit on a bread board connected to the Raspberry Pi. The input, output, and power supply were modeled right from here. Only the toggle and the 3PDT button were used from the diagram.

Starting with the input section of the circuit, we loosely followed the diagrams to connect the input jack to an operational amplifier or op amp. The signal then flows through two 1MΩ resistors, two 4.7kΩ resistors, one 100kΩ resistor, two 6.8 nF capacitors, a 0.1 uF capacitors, 270 pF capacitors, a resistor trimmer and a 4.7 uF electrolytic capacitor (see circuit), and the Analog Digital Converter (ADC) before finally going via the Serial Peripheral Interface Bus into the Raspberry Pi. We used the diagrams on this site here to properly orient the op amp. There is a diagram on the circuitry at Electrosmash that depicts the pins on the Pi for hookup but a clearly image can be found here which we used for various things including finding alternate pins for testing.

From various leads in the input, the circuit flows into three separate power supply circuits. Two of which contain two 220 uF electrolytic capacitors, a 300Ω resistor, a 100 nF capacitor and into both the 5V pin and the 3.3V pin on the Raspberry Pi. The other power circuit contains a 50kΩ resistor, 100kΩ resistor, a 4.7k uF electrolytic capacitor and into the 5V pin of the Pi. The circuit then enters the output stage of the circuit, which sends the signal back through three 4k7Ω resistors, a 300kΩ resistor, three 6.8 nF capacitors, a 4.7 uF electrolytic capacitor, into another op amp and into the output jack (see circuit).

Once we had the circuit fully built and working on the breadboard, we started to transfer the circuit onto the circuit board. We knew that it was likely that there was going to be a mistake or cold joint on the circuit somewhere, so were sure to diagram each individual section making it easier to debug later, if necessary. Once we had the circuit diagram drawn, we used duplicates of each part making sure not to break the circuit that was already working.

Debugging the Circuit

Debugging was the most important part of this project. Following both the initial build out of the breadboard and the first soldering of the final circuit there was no noise. Both times debugging strategies had to be used to find where the error in the circuitry was and how to fix it.

The breadboard and the soldered version had different aspects that could lead to failures. The breadboard could have bad connections in itself and the soldered version could have connections that were not properly soldered. In the breadboard an LED was used to make sure that each row and column of the breadboard that was being used was connected and functioning properly. The LED was wired to a GPIO pin and the pin was set to HIGH. If the LED lit we knew that this section of the board was working. To test connections on the soldered circuit an Ohm Meter was used. One lead of the Ohm Meter was placed on one side of the connection to be tested and the other lead on the opposite side. If the meter got a reading than the connection was good and functioning properly.

In terms of larger debugging we applied a few strategies to both the breadboard and the soldered circuit to identify where possible issues would be.

To test the output we wrote a test code that made the Pi use the pulse width modulators to create a test signal that was sent directly to the amp. If the signal was heard than the output side of the circuit was functioning properly.

To test the input side again test code was written. This time the code printed the read out that the Pi was getting from the ADC which should in a normal scenario be fluctuating between inside the threshold of 0 to 4095. If this was not occurring than the issue was in the input side of the circuit. To narrow down where in the input there could be an issue we looked at these readings. If the input was reading top threshold (4095) constantly, we knew that the Pi was getting too much from the ADC and this was likely caused by a part of the input circuit not grounding properly. If the input was reading the bottom threshold or lower than it should than we knew that there was a wiring issue or a scenario where there was a faulty bypass.

The code for the two debugging processes can be found here. Go to the testing folder on the github to see the various codes.

Final Code and Case Design

Jared's writing about code and how the effects work. Also discuss auto run that had to be setup.

https://github.com/jaredmalkin/dontfret

The case that had to be designed had to contain the Raspberry Pi 3, the circuit board that contained the whole effect circuit and the switch/LED sequence, and the jacks. The case also had to have the integrity and strength required to hold the pressure of a foot on the pushbutton for many uses. For the purposes of designing a case with possible collaboration and check-ins OnShape was identified as the best platform for designing the case. OnShape had enough depth to properly design a functional case and also the online platform allowed for easy multiuser work.

The actual case was 18 cm by 16 cm with a height of 7 cm. The case was designed accounting for the possibility of a larger space requirement that could of arose when the circuit was being soldered. The designed case had riser with holes so that the Raspberry Pi and the main circuit board could be screwed down so that there would be no motion inside the case during use that could lead to faults. The cases walls had to be 0.25 cm or thinner so that all the jacks and switches could properly integrate into the design. This thinness of wall and size of box made the strength of the open box very small. Further work had to be done to make sure that the design could take the pressure. To accomplish this we moved the push button location to the corner and built out the wall in that area, essentially making a pillar support that could take the pressure of the foot and still stand. To further this we planned to make the infill of this area higher than the rest of the case. This design can be found on Thingiverse here, and is pictured below.

• 

This designed case was not used in the demonstration because of issues with the 3D printer and a miscommunication error in the UltiMaker 3 that could not print a case of the size that we designed. To make sure that there was still a functional case we ordered a vanilla case off of Mouser that we modified slightly to serve our purposes for the demonstration.

Finishing Stages

Results

Our group was satisfied with the completion of our project, although demonstrating with the designed case would of been the perfect outcome we saw no failures in the project as we thoroughly designed the case and the error occurred in the printer and not on our end. The pedal successful took in an input from a guitar and sent an output to the amp. The pedal successfully ran clean, distortion and delay on the day of the demonstration. Some of the major bugs we ran into are listed in condensed form here:

• Electrical connections in the breadboard are not always the best and testing their functionality was challenging.
• Our process included many parts that relied on other parts to be completed for full integration and testing. Properly designed and creating brief individual tests would alleviate this.
• Error while printing the case.
• Ensuring that solder points were good connections and that cables would stay properly attached to Raspberry Pi through motion.
• The wiring of the circuit was a bit unprofessional because making a working circuit was the ultimate goal. Improving this would lead to a possible reduction in size and more confidence in the circuit withstanding many uses.

Final Presentation

Located below is an image of the final poster that covers the broad topics of our project. This poster was presented on demonstration day.

• 

Next Steps

The next steps of the Don't Fret project will focus on size, budgeting, and increased functionality. The next iteration would use a multi-dial switch that allow for many more than two affects to be triggered by a single pedal without changing of the code. Additionally, the Raspberry Pi 3 can be swapped out for a Raspberry Pi 0 which cuts down size but also price dramatically. Improving the circuit so that it fits on a smaller breadboard would also reduce size. Finally, the creation of a database or flashdrive function that would allow users to automatically select and download code for different effects to the Pi would lead to easier use.