This week, I did the ethics assignment, worked multiple times with Chaitanya to help finalize our hardware design, made initial plans for the housing model, and discussed restrictions for the housing model with someone from the 3D printing lab. We needed to finish our hardware design before I could start work on the housing model, since the dimensions of the model will depend on the specifications of the design. I did rethink my original idea for the housing to reduce risk, now planning to split it into 3 parts, with the top faceplate being its own part. This is because the faceplate is the part that relies most on the hardware design, so making it its own smaller part that can be slotted in easily allows me to make multiple possible designs and quickly adapt and refabricate the design if we run into any issues with our PCB design. Our progress has caught up a bit from where it was last week, and we expect to be fully caught up by the end of next week. Next week I hope to finish the models for the lower housing and the functional pedal, make an initial version of the faceplate model, do the in class portion of the ethics assignment, prototype with my group in lab to test some components we ordered, and start helping with the software if I have enough time.
Team Status Report for 3/15
The current most significant risks are in our PCB and our interface components. For our PCB, because of the time and cost it takes to get it made, we are unlikely to be able to fix any issues that come up after fabrication. To mitigate this, we are working to look over any possible issues that could come from voltage mismatch or positional issues, and have backup plans in case an issue still arises, including full backup perf boards already ordered and plans for smaller perf board designs that could be easily implemented along with the PCB if the issues are coming from the input or output. For the interface components, the main risk is that they do not work at all or as intended, so we will be testing all of them in prototyping over the next few weeks to ensure that they work. One major change was made to the existing design, with us getting rid of the row of buttons for pitch shift and adding their functionality to the LED buttons we are using for beat selection, with the pitch shift option on the slide switch altered to allow for this change. We did this after realizing that physical switches for the pitch shift buttons would not work if only one beat could be modified at a time, as they would allow for multiple to be turned on. The LED buttons allow us to provide visual feedback for a beat being unselected as another button is pressed. There are no major costs from this change, as it requires no additional hardware and just shifts some of the software work left to do around.
Team Status Report for March 8
Our biggest risks remain that any of our components do not function. Thankfully, the Daisy Seeds have arrived, and they have no apparent issues, so we have a microcontroller and a backup. However, we still have more components that have yet to arrive. We have configured a list of materials that we will order, and we plan to test them rigorously so we know that they function as intended.
This week, our design has stayed more or less the same. We have configured some finer details, including the size of the PCB that will be housed in the pedal.
Our schedule has not seen significant changes. Some issues have pushed work into slack time, so we are somewhat behind schedule, but our order of operations remains the same.
Part A (Chaitanya Irkar):
When designing and conceptualizing our pedal, one of my primary initiatives was to deliver a compact, easy-to-use product that could be enjoyed on a global level. We understood that not all consumers of our product will have access to the same high-quality resources available to us as CMU students. Emphasis on portability removes an physical restrictions for transporting or even delivering the product to individuals around the globe. It can also easily be shared by bandmates, gifted to friends, and easily stored in any environment, making it catered to individuals of all musical backgrounds. We also spent a significant amount of time designing our pedal interface (knobs, switches, buttons) to make it easy to adjust and view pedal settings. The only “complex” component of our design are the pcb board and Daisy microcontroller. These components will be hidden inside the pedal casing, limiting access to any harder-to-use parts. While our product does promote usage amongst people all over the world, it does require a power supply which could serve as an obstacle for users in areas of unsteady electricity. Such a factor is difficult to mitigate in the context of a guitar pedal design due to the necessity of a power supply to operate. However, we hope that our basic user-interface and other design choices will compensate for any other shortcomings outside of our control.
Part B (J. Frantz):
Our pedal will allowsfor users to subdivide the repeat period into either four or three portions, matching how most contemporary music uses binary or ternary meters. These encompass the most simple divisions of time in music, and there will be a wide range of customization granted by allowing the user to select a meter.
Notably, our pitch-shifting is planned to use 12-tone equal temperment tuning in order to calculate the intervals. This is a standard that is used throughout most contemporary music today, but this is not the only tuning system that exists. Microtonality is prevalent in genres like Indian classical music, but our pedal’s pitch-shifting will not account for this.
These simplifications are design choices made with a semester’s scope in mind. Our primary goal is to make a device that is useful for a wide range of musicians, and we wanted to keep our design simple enough. Allowing for a wider range of meters and tunings is a possible goal for further improvements beyond our capstone.
One important cultural factor to consider is that the general public would not like to be subjected to excessive noise. Therefore, in our delay mechanism, we will restrict the amplitude scalar for each successive delay to be not more than unity. This will ensure that the input sound will not grow exponentially loud and harsh for people in the vicinity.
Part C (Nick W):
The main environmental considerations for our project come in production and the energy efficiency of operation. For production the main concerns are the materials used, and how they are produced. Considering this, we are using mass produced interface parts, which don’t have much environmental impact, 3D printing our casing to minimize waste, and using a standard PCB manufacturer, but would likely search for an environmentally friendly manufacturer if these were mass produced. For energy efficiency, we can’t save power in many places since we need most components to be on while the effect is active, but we will turn off some parts such as the screen when the effect is off.
Frantz’s Status Report for March 8
This Week’s Accomplishments:
This week, I continued to make progress on the pitch-shifting algorithm. I retrieved the Daisy Seed microcontroller, and verified that it connected with my computer so I could load a program onto it. I also began teaching myself how to program in C++, as the Daisy Seed uses that language to be programmed.
Status:
My progress is slightly behind schedule since I haven’t finished programming the phase vocoder algorithm, but it is moving along steadily.
Next Week:
Next week, I will reconvene with the team after spring break. I plan to continue programming the phase vocoder pitch-shifting algorithm, and I will research how to rewrite it in C++, a language I am a beginner in. For example, I will determine if I need to write my own direct Fourier transform algorithm or if I could import one.
Nick W Status Report for 3/8
I wasn’t able to accomplish much this week as I got sick at the start of the week and it lasted for the entire week. With the energy I had, I prioritized finishing my part of the design report and preparing for two midterms I had for other classes. We are still behind for the same reasons we were before, as with midterms and my illness we didn’t have time to catch up on work, but we will in the next two weeks, so we will try to get back on schedule in that time. In the next week, I hope to get an initial version of the 3D model done to revise with my group, and work with Chaitanya to help with PCB work.
Chaitanya’s Status Report for March 8
This week, I focused on getting the PCB layout off the ground. My first obstacle was finding the proper layout footprint in a PCB design tool. My familiarity with Autodesk Fusion360 led me to look into finding a footprint in the Fusion360 library. After conducting extensive research in the Fusion360 library and looking for download options online, I concluded there were no options to proceed with Fusion360. I looked into alternatives and settled with using KiCad for my layout tool as the Daisy footprint was uploaded to the open source library in KiCad. I have attached a screenshot of the print below.
I then looked into the standard sizing of guitar pedal casing to determine the size of the board. After conducting brief research, I decided to size my board with a width of 2.85” and a height of 5”. I have defined the board outlines in my layout. In addition, I contributed to the design requirements and system implementation portions of the design report, amongst other minor formatting contributions. As part of the report, we finalized an initial draft of the bill of materials. While further discussion is needed to determine if any more components are required for our product, this initial list allowed me to begin my search for layout footprints of materials in the KiCad library and online. My next goal is to use the pinout of the Daisy Seed to begin connecting the I/O pins and power pins to the appropriate components.
I am still on schedule as the barebones of the PCB are coming together. I hope to have a board layout next week. I also want to begin prototyping my components on a breadboard. However, this might temporarily be on hold until I can determine basic tests to prototype as waiting for full functionality of our desired features will take too long and limit the duration of time for which I can prototype.