Posted on

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.

Posted on

Chaitanya’s Status Report for April 12

This week, I completed the schematic and layout for our PCB. I resolved several issues with the PCB including fixing one of the LED button footprints to allow me to control the LED for the button via microcontroller GPIO. I placed and routed the PCB, uploaded the files to JLCPCB, ordered the PCB, and received confirmation from Quinn regarding the PCB order. The PCB should be arriving by the middle of this week. The back half of this week was dedicated to testing Nick’s GPIO code. All connections are still on the breadboard. There were some issues with getting the Daisy Seed to connect with Nick’s computer, so he created a Github to track test .cpp files that I pasted into my editor and downloaded onto the micirocontroller. His code successfully interacts with the 4-mode switch and is very close to working with the 7-segment display (on segment of led not working). Nick has implemented a timer-controlled flashing feature that flashes rapidly between all characters of the display, giving it the effect of all characters displaying at once, which he and I were able to verify was displaying. The button code seems to not be working likely due to the way they are being initialized. Nick has updated the code, and I will be testing it this weekend.

For my portion of the project, verification will come in the form of PCB validation. This means ensuring that once soldered, the code that we have found to work with the breadboard prototype will also work with the I/O components on the PCB board. Due to the uncertain nature of the PCB board, there is a slight possibility that the board malfunctions due to certain faulty connections. Due to this possibility, I am dedicating the beginning of this next week to building the same breadboard prototype on devboards where we can solder the components and wire components. This will serve as a backup to ensure that the user can properly interact with our pedal. Further testing will involve measuring currents and voltages along all GPIO pins to ensure that the proper current is supplied to I/O components. In my PCB, I have placed surface mount components to serve as current-limiting devices, but this is still important to avoid breaking components close to demo day.

In relation to our timeline, I think my portion of the project is coming together fine. The biggest issue would be if the PCB is not working as desired, in which case we might have to pivot to the dev board soldering for the specific components that have faulty connections. After getting the switch and 7-segment displays to work at the end of last week, I am more confident that the hardware components of the project will be finished in time. I will also need to potentially add hardware for the input and output audio, but I should be able to figure that out by the end of this week. The window is getting narrower, but I still feel that we can get a solid pedal in the end.

Posted on

Nick Status Report 4/12

The past two weeks, I have assisted with verifying the circuit for the PCB, made the interface code for the pedal, created test codes for debugging the pedal, met with Chaitanya to debug the interface code, modified the plans for the 3d model due to changes with the PCB, and made designs for the input circuit. The interface code is mostly working, with only the buttons and the rotary encoder still having issues, but this is likely due to some confusion with the Daisy library, as the classes for switches and encoders seemingly are in progress. I have already made some alternate files to test possible solutions and am working on making versions of the code that use the standard GPIO class, which we know works as I used it for the other components, but I am hoping that we can get the Daisy classes working as their debounce function would likely work better for our pedal. For the 3D model, after learning that the PCB size would be much larger than initially planned, I remade the models to fit the new PCB and sliced them, and it seems that the base at this new size would be too expensive to print, so I moved the holes for connections in the base to the faceplate, and will find a premade plastic box that we can use as the base. Overall, this shouldn’t affect the functionality. Our progress seems to be slightly behind, although not by much, as we should be able to catch up early in the week and hopefully start testing. Next week, I will fix the last few things with the interface code, add the holes to the faceplate model and send it for printing, finalize the breadboard version of the circuit for testing, start testing once the audio processing code is fully converted to C++, do my part of the presentation slides, and prepare for the presentation.

As for testing of my own subsystems, as of now, I made most of the circuit in tinkercad while we were designing to test functionality and have made and modified multiple test files for the interface code to debug the individual subsystems of the interface. For the tests I plan to do in addition to the tests we are doing on the whole system as discussed in the team report, I plan to test the system with the full code and compare it to a preset input with just the audio code to determine if there is any significant impact from the interface code on latency, and plan to test the overall noise impact of some of the changes in our design.

Posted on

Frantz’s Status Report for April 12

This Week’s Accomplishments:

This week, I spent a lot of time working on my C++ code, to be loaded onto our microcontroller. I have completed most, but not all of the real-time pitch-shifting algorithm, with quite a few roadblocks. The first was that I found great difficulty in importing a library for computing the Direct Fourier Transform. In order to minimize the difficulty of interacting with a new interface, I wrote my own DFT code myself, following the Cooley-Tukey radix-2 algorithm. I also wrote code for the Inverse Direct Fourier Transform, which was a simple edit of the DFT code.

Here is my current DFT code, with some print debugging commented out:

I have not yet optimized my code for quickness or implemented garbage collection, which will be necessary for programming in C++. However, I have tested my code and found that for a few test inputs, my output matches that of the Python function “numpy.fft.fft”.

I have found some difficulty in converting my previous Python algorithm not just into C++ but into a real-time operation. This is still in-progress. I will need to test my code’s performance to ascertain what amount of latency is safe.

I have used the micro-USB cable I ordered to connect our microcontroller to my laptop. Next week, I aim to start by learning how to use the Daisy Library to receive input samples and send output samples. I will then implement the “delay” functionality, which is comparatively simple.

We are somewhat behind our original schedule and a little pressed for time. Nevertheless, we are confident in our ability to complete our project in the next week. I will spend a lot of time completing and testing my code within the next few days.

Posted on

Frantz’s Status Report for March 29

This Week’s Accomplishments:

This week, I began programming in C++. I first created functions to extract samples from a .wav file and create a new .wav file using a list of samples. This allows us to easily test our algorithms using imported sound files. Then, I began reworking the pitch-shifting algorithm in C++. I am modifying it so it completes the task in chunks, which is vital for outputting data in real time with minimal latency. I tried importing the FFT library “shy_fft,” but it doesn’t seem to work properly. After a lot of troubleshooting, I switched to “FFTW.”

Additionally, I ordered a micro-USB cable with data transmission for connecting our microcontroller to a computer.

Status:

Our schedule is on track, but time is getting tight. We will stay diligent to complete our project satisfactorily.

Next Week:

Next week, I will continue rewriting the phase vocoder algorithm for real-time use in C++. I will test the FFTW import to ensure that it works properly. When I am done, I will start writing the delay algorithm.

Posted on

Nick Status Report 3/29

This week, I was unable to work much, as I was sick and had a major lab for another class. With the time I had, I researched some other daisy projects to make a plan for the device code for our pedal, so that we can start integrating everything. My progress is slightly behind because of the setbacks from this week, but I have plenty of time in the next two weeks to make up for it. Next week, I hope to get the base of the main code done so that we can test the code Chaitanya has been working on with our audio processing code, and I also hope to get the 3D model finished if the PCB is done in time.

Posted on

Team Status Report for March 29

Primary risks involve not being able to get the systems integrated on time. Josie has made good progress prototyping the pitch shifting and delay features in python and is working to get them in C++ for the microcontroller. Chaitanya is looking to wrap up prototyping with the Daisy Seed and I/O components on breadboard in the coming week. Nick has preliminary casing 3-d models. The integration of these different parts will, therefore, be our next challenge. We are looking to address this next week once all of the different subsystems are fully functional. This will involve extensive discussion on the interfaces of our separate modules and a push in the next few weeks to experiment amongst our different parts.

No changes to the existing design. Potential changes could be made to the hardware in case there isn’t enough time for the PCB and the breadboard implementation is working (which seems to be the case at this point). Schedule should be sufficient but we will be heavily emphasizing system integration in this final chapter of our project. Please reference individual status reports for detailed pictures/diagrams of our individual progress.

Posted on

Chaitanya’s Status Report for March 29

This week, I continued working on the PCB design. I attempted to resolve issues regarding the pinouts provided on the data sheet with Gordon but decided that testing of the physical component was the most efficient way of matching the schematic pins to physical pins for components that had vague data sheets. However, since there was an extensive delay in getting our components despite putting an order weeks ago (just got them on Wednesday), my progress at the beginning of the week was hindered. Once I got the components, I immediately started on the breadboard prototype. My goal for this week was to understand the pinouts of all components and set up the breadboard prototype with the daisy seed mounted. I was able to successfully test and identify the the functionality of all pins for all components. I did this using the DC power supplies in Tech Spark and an LED to verify that buttons, switches, and 7-segment display were working. Here is my current progress on the breadboard. The headerpins came with the daisy seed. We originally ordered a non-soldered microcontroller, but ordered another one recently with soldered header pins.

The delay in getting the components halted my progress on the PCB as I couldn’t proceed for some of the buttons until I was confident which pins in the schematic corresponded to the schematic pins. It also delayed my progress on the prototype. Hence, I am slightly behind schedule. My plan is to establish a connection between the daisy seed (goes on top of the header pins in the picture) and the I/O components by displaying print statements everytime an interaction with a button, switch, etc. occurs. I would like to be able to demo this during next week’s interim demos. However, we are also waiting on the the micro-usb cable used to program the Daisy. We had originally thought we placed an order, but when it didn’t come with the rest of the components, we realized that it was not placed and immediately placed another one. I strongly believe that my connections in the picture above are correct as I tested them with DC power supply/LED successfully. Hence, the primary concern is familiarizing myself with the daisy interface. While Josie will be primarily in charge of the 2 features of our pedal and getting them working with the microcontroller, I need to be able to program I/O features using the interface.

Given the limited amount of time we have at this stage, I will be heavily investing my time in getting a breadboard prototype fully functional over the next week. The PCB will serve as a bonus version of the prototype but getting a basic implementation working is my first priority. Once I am able to set up the Daisy Seed GPIO connections, I hope to resume work on the PCB, fixing the connections in the schematic/layout according to the testing of the physical pins I completed this week and early next week.

 

Posted on

Frantz’s Status Report for March 22

This Week’s Accomplishments:

This week, I have written the phase vocoder algorithm in Python. It successfully shifts our test tone by a given number of semitones up or down. There are currently some harmonics introduced in the process that I will need to debug, but the output is coherent. I also tested the input levels coming out of a guitar using an oscilloscope. I noticed that there is a significant amount of noise above the threshold of human hearing. So, we decided that we can use a simple RC filter to remove the noise before the signal gets input into the Daisy Seed. This should avoid any issues with aliasing. We also completed part of the Ethics Assignment this week.

Status:

Now that the phase vocoder pitch shifter works, progress is back on track.

Next Week:

Next week, I will start rewriting the phase vocoder algorithm in C++. Notably, for real-time input, I will need to use a circular buffer to store the signal while each batch is being operated upon. I will determine if I need to write a fast Fourier transform algorithm or if we can import a (or use an already-imported) library.

Posted on

Nick Status Report 3/22

 

This week, we started by doing part 4 of the ethics assignment Monday. Then, I made the base of the 3D model for the pedal housing to confirm the initial design ideas with the group Wednesday. I can’t add the holes for the components yet, as the PCB layout isn’t complete yet, and will be mounted to the other side of the faceplate, but I discussed more with the 3D printing lab to ask about restrictions and design requirements so that I can add the I/O holes and send out the designs for printing once the PCB is finished. In lab Wednesday, we discussed the initial model and tested our audio input component to find if we needed to make any adjustments to our schematic. I also worked with Chaitanya further to fix some issues we had with the design, swapping out some parts and adding some components to deal with pin issues on our microcontroller. We are mostly on schedule, although we are having to shift some parts of the schedule around due to some work relying on other work to be completed. Next week, I will start on the implementation software, although one of my other classes has a major lab that will keep me busy early in the week.