Don't Fret
Contents
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
- 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
We coded our program in c, a new language for all of us. We first looked at the example code for a clean sound given by electrosmash.com, which gave us a general outline of how to go about the technical parts. We learned how to start the BCM2835 library and the SPI BUS, define the pins with the right configurations, and get the MCP3202 ADC reading how we want it to.
First, we define all the input pins on the pi. We use three GPIO pins, managed by the BCM2835 library. We also define an input_signal and an output_signal variable, FOOT_SWITCH_val and TOGGLE_SWITCH_val, which are used to read from the button and switch, as well as some variables for the effects.
In the main function, we initialize and start the BCM2835 library and the SPI BUS. Then we define the pulse width modulation through 2 channels, configure the SPI BUS, and define the GPIO pins (the toggle and foot switch as input pullup, and the LED as output). We then have a continuous while loop (while(1)) that runs all of our functions. We first read 12 bits from the ADC and put the result into the input_signal variable, which reflects the voltage coming in, ranging from a value of 0 to 4095. Outputting this input_signal would give us a standard, clean sound straight from the guitar without any effects. Using a timer variable that is incremented every iteration of the while loop, we read the values from the toggle switch and the foot switch every quarter of a second (every 50000 iterations). Finally, we get to manipulating the input_signal variable, creating effects. We have an if-else statement that says if the toggle switch is off (if TOGGLE_SWITCH_val is 0), we go to the distortion effect. This effect works using a threshold around the average value of input_signal, 2047. The effect manipulates the sound wave by clipping any values above the threshold to the maximum value allowed by that threshold, and any below it are clipped to the minimum. We used a value of 100 for our threshold, so any time the input_value goes higher than 2147, we set the value to 2147, and when input_value is below 1947, we set it to 1947. The new value is then output, and a distorted sound is heard. Then if the toggle switch is off (the else statement, if TOGGLE_SWITCH_val is not zero), we go to the delay effect. This effect uses a Delay_Buffer array to save the sound wave coming in, and outputs the saved values on top of the current values about a half second later. This is done with another timer that helps put the saved signal on top of the current one when it hits 100000 iterations.
We still had to solve the problem of running our program right when the raspberry pi boots up, since when the pi is inside the pedal, we only have access to the power supply port. We went into the file ~/.config/lxsession/LXDE-pi/autostart and added our program with the line: @sudo /home/pi/dontfret. Once we did this, our program started running about 15 seconds after plugging the pedal into a power source.
All of our code can be found in this Github repository.
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. Also attached below are photos of the final product from both the outside and the inside of the case.
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.
