Team Status Report for April 12
The most significant risks we face are the PCB not working, the microcontroller taking too much time to complete the operations, and the output being too noisy. We have contingencies for all of these possibilities: we are making a backup devboard for connecting our components if our PCB is faulty, we are using a low-pass RC filter to remove high frequency noise from our output signal that could cause aliasing before our microcontroller’s ADC, and we are prepared to change macros in the code that will change the window size in case 2048 samples is too many for low-latency pitch shifting.
We slightly changed our implementation, primarily in the physical structure of our pedal. We are accommodating a PCB with a larger size than originally anticipated. Overall, this shouldn’t change costs too much; it may require slightly more 3-D printing material.
We are slightly behind schedule, so all of our remaining work will be compressed into the remainder of our time. We will each be devoting a lot of time to covering the last touches of our implementation, testing, and our final deliverables.
We are planning to test our pedal by measuring its output by ear and using an oscilloscope. This should allow us to measure our latency (by calculating the difference between the peaks and troughs in our input and output signals) and signal-to-noise ratio with precision, and we can ensure our pedal works within our use-case requirements. We will be sending musical signals into our pedal via a function generator and a guitar (including multiple styles of playing) as well as chaining our pedal in series with other pedals, to ascertain that our pedal works in a real-life setting. Naturally, we will be running tests with all of our pedal’s parameters and ensuring that changing the parameters during use poses no issues.
Team Status Report for March 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 February 22
So far, the biggest risks remain the same as last week, mainly with components or parts of our design not working as intended or being broken. We have ordered multiple of the parts we have decided on and will order multiple of future parts to mitigate this, as well as planned for alternatives to our PCB if that doesn’t work. We also considered some alternative methods to implement the current planned features of the pedal, as our microcontroller is more specialized and none of us have ever used it before, and while we have tried to look for any issues in planning, we need backups in case we miss something.
No major changes have been made to the design yet. With this being a week many had midterms, we did not have as much time as in previous weeks, so we prioritized getting the design presentation done and prepared for, as well as getting a start to the report. We have some concerns about the design, as it seems from the feedback of our presentation that there was some confusion about the way we explained the functionality, so we will discuss this further in our meeting Monday.
Team Status Report for February 15
Currently, our most significant risks are the possibilities that the components we receive arrive broken or stop working during testing. We are addressing this by ordering extra parts to use in this case.
This week, we made many changes to our prior designs for the pedal. We settled on using rotary encoders for our dials instead of potentiometers, and we decided on a mechanism to control pitch-shifting. Pitch-shifting greatly increases our pedal’s functionality in a way that will be beneficial to our end users. Using potentiometers would limit our dials to controlling one parameter each, so we rejected that idea so that one dial could control pitch shifting for any of the sequence beats. We decided to use the delay time’s rotary encoder to change the pitch (in semitone increments) to whichever sequence note is selected among a set of switches. We also decided to allow users to mute the first note in the sequence, which we imagine could be useful and easy to implement.
Our schedule has more or less stayed the same. We are not behind on anything, and we anticipate having time to spare in case any of our components arrive late.
Part A (J. Frantz):
Our pedal will be a tool for making art, but there are still important safety issues to take into consideration. For starters, our pedal should be sturdy enough to withstand a person’s stomp. If our pedal were to shatter if someone presses too hard, it could send pieces flying and potentially injure someone. Also, it could expose our circuitry, which would be a shock hazard. Given that we want our pedal to be used indoors or outdoors, we want our pedal’s insides to be safe from the rain. So, we should ensure that the casing is water resistant.
Part B (N. Walker):
Our pedal should be usable by people from many different cultural and social backgrounds, and the most significant consideration for that is making sure anyone can understand how to use it. We cannot expect everyone who might use our pedal to speak the same language, but as it is an effects pedal for instruments, we can expect that they will understand basic musical terminology. Knowing this, we can use musical terms on the interface, such as “tempo” for delay time or using the terms for different beat patterns to control the delay patterns, and therefore make it as culturally accessible as possible.
Part C (C. Irkar):
By producing a single pedal, we provide an affordable alternative to expensive music technologies that have a wide range of functions that might not perfectly meet the needs of the user. A custom pedal allows us to cater to the needs of guitarists while reducing the cost of hardware, making it more cost-effective to produce and distribute. The compact design of our product makes it more portable, enabling musicians to easily transport our product and use it in an environment of their choosing. While the functionality of our pedal is our top priority, having a user interface that is straightforward and easy to use is something we will push heavily for. Our goal is to create a product that both an amateur and a professional can use. Considering these economic factors will mold our product into a user-friendly, affordable, and portable device that can aid any musician.
Team Status Report for February 8
Our team worked on finalizing our proposal (slides) and ironing out the schedule for the upcoming weeks. In doing so, we saw that some of the significant risks for our timeline include delays in getting our PCB back from fabrication. In addition, delays in getting our microcontroller and other hardware components could significantly impact our progress. From a design perspective, the PCB, 3D printing, and user interface don’t pose immediate risks. However, our choice of microcontroller (Daisy Seed) could prove to be a risk as none of us have previously used it (in contrast to other microcontrollers like STM32 or Raspberry PI). Our preliminary research indicates that this risk should be minimal, but our contingency plans involve using an FPGA or microcontroller from the school inventory that meets the specs that we desire.
Our decision to go with the Daisy was the only design “change” that we made over the past 1-2 weeks. This “change” was more of a narrowing of our options to a singular implementation. No changes in cost are to be accounted for as purchases have not been made.
The initial schedule was finalized this week. The schedule will be updated as needed in future status reports.
Our group looks to wrap up the research phase of our project and begin making order requests in the next few weeks.