Team Status Report 4/26
This week, we tested the PCB and found that it was having some issue, so we shifted to getting a functional implementation using perf boards to ensure that we have something to demo. If some members have spare time, they may try to find the PCB issue and fix it after the perf board implementation is tested, so we may return to a PCB implementation by the demo. We had planned for this situation, and used backup designs and backup parts ordered earlier to make the perf board version, but there will likely still be some effect on the noise within the signal due to this change. The main risks are that something with the perf board version does not work in testing, which is unlikely due to our previous prototyping but would be very bad for the project, and that something with the final audio processing code has an issue. As the perf board implementation was already the backup for the PCB, our options for backup plans are limited, but we do have some plans for how to manage certain issues if they come up.
Unit and System Tests:
Audio Processing Software Testing: Simulated the code in python with a premade audio signal, found that the delay was fully accurate and the pitch was shifted to the correct note.
Microcontroller Testing: Testing the Daisy Seed for latency and accuracy of delay effect, found minimal latency from the MC itself, and that the delay effect was providing the expected outcome.
I/O Testing: Testing the I/O code with a prototype circuit to make sure it functions correctly, had some issues with the library used for the microcontroller, but fixed them and got I/O fully functional.
Prototype Testing: Testing combine audio processing and I/O code with prototype version of the circuit, found that delay effect produces less than 0.5ms of latency, is accurate, and that the amplitude attenuation is accurate within 1 percent of the goal, all while the I/O code is fully functional.
Full System Testing: Testing final implementation for correctness and that all the metrics from previous tests are maintained, as well as testing for pitch shift accuracy on final implementation and for signal to noise ratio. Not finished yet due to delay from PCB issue, should be done Sunday or Monday.
Team Status Report for April 19
Our most significant risks are if the Daisy Seed microcontroller doesn’t work as planned. We have already had to modify multiple segments of code to sidestep issues that have popped up, including not being able to access most of our microcontroller’s memory without a specific keyword. The Daisy user forums have been helpful for solving a lot of issues like this one, thankfully. Nevertheless, we are planning to complete more intermediate tests to catch any more issues that arise. We are also awaiting the arrival of our PCB, but we have connected our components with a wired circuit prototype, which works in our tests. We will build a soldered devboard as backup.
The only major change in our implementation was inserting an RC low-pass filter both before and after the signal passes through the microcontroller to cut out high-frequency noise. Also, we have made a few implementation tweaks. We have modified some code to account for quirks in the microcontroller, and we have made backup circuits for connecting our components.
We are slightly behind schedule, due to the PCB arriving late. However, we have been making major progress in integrating our parts together. Our tests have been fruitful. We will be testing extensively this week as we bring our individual components together.
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.