Posted on

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.

Posted on

Chaitanya’s Status Report for April 19

What did you personally accomplish this week on the project? Give files orphotos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week was focused on integration and getting some software features working. At the beginning of the week, Nick and I worked on testing and debugging the user interface code. We were able to verify that we were capable of interacting with all buttons, switches, displays, and LED’s. One of the digits was previously not properly displayed in the 7-segment display. We switched the Daisy microcontroller that I soldered with a pre-soldered Daisy Seed and found out that the issue was with a pin that I didn’t solder well (oops!). By Wednesday, we were able to verify that all I/O components had working code that could be directly integrated into Josie’s sequencer code. All work is still with the breadboard prototype. We will be getting the PCB that I designed about 1.5 weeks ago this coming Tuesday. We will be using Nick’s code to test that board’s functionality and tend to any buggy components/connections on my board by incorporating (somewhat janky but functional) fixes on the PCB. The backend of the week was focused on integration and initial testing. Josie and I met on Friday to get the sequencer code working. After resolving syntax issues, I saw that there was an error with the way the data was being allocated on the microcontroller. It was being allocated as SRAM memory instead of SDRAM memory and was exceeding the total SRAM memory amount. Hence, Josie and I looked into ways to get the code to rely on SDRAM memory instead to give more memory to work with. After some research online, I found out that the Daisy Seed microcontroller has a macro that allows the use of SDRAM memory. After implementing this change in variable declaration, we hooked up Josie’s guitar to the audio input on the Daisy via an audio jack and hooked the output to an oscilloscope. We saw confirmation that hard-coded delay was showing up. We then used one of the small speakers in the 220 lab to verify the output by ear.  Today, Nick, Josie, and I were able to integrate the button code with Josie’s code to create a functioning sequencer system that used the button inputs to specify the tempo and amplitude attenuation instead of using hard-coded values (big milestone achieved We have taken pictures of the oscilloscope and took latency, frequency, and amplitude measurements to verify functionality and measure validation metrics.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am slightly behind schedule but on track to have my part fully functional pending the PCB coming on Tuesday. I will work to validate the PCB and build a backup devboard if needed.

What deliverables do you hope to complete in the next week?

While our group is doing well, I am slightly concerned about the PCB. The delay and getting it shipped has given very little time to validate full board functionality. However, I have leveraged JLCPCB’s component place and soldering service, so there isn’t too much to be soldered. The real challenge will be resolving any issues with specific PCB components. As a backup, I will immediately build a dev-board soldered implementation of our I/O circuitry after checking board functionality. Given that we have a functional worst-case backup option with the breadboard, this should not take long. This next week, I will continue to help Nick and Josie test the functioning pedal parts, validate my PCB, and build a backup devboard if necessary.

As you’ve designed, implemented, and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

When picking PCB components, I had to be able to work with Nick to search for components on Digikey. I developed this skill by playing around with different filters on the Digikey website and checking the results. The next step in implementing my PCB was identifying the correct tool to do my layout. I searched through forums to see if there were Daisy symbols/footprints available in Autodesk Fusion360, as it was the tool I’m most familiar with. After seeing that I needed to use KiCad to complete my layout, I viewed countless youtube tutorials to understand how to download EDA/CAD models and update KiCad symbol libraries, build my schematic, download corresponding footprints, passing ERC checks and DRC checks, producing Gerber and bom files, and, finally, sending out my PCB for manufacturing through JLCPCB. During the recent debugging phase, I had to find solutions to small problems in my partners’ code. I used discussion forums on the Daisy Seed microcontroller and kept searching until I found an exact viable solution. I also refreshed usage of the oscilloscope by playing around with the scope settings.

Posted on

Frantz’s Status Report for April 19

This Week’s Accomplishments:

This week, I made some more progress on the real-time pitch shifter. In the meantime, I also wrote code implementing the “delay” and “sequencing” functions.

We spent plenty of time testing our microcontroller with input from a function generator and a guitar, sending the output to an oscilloscope. We got our microcontroller to succeed in a few tests: first, we had it send input to output unmodified; then, we had it repeat an input once; next, we had it operate with the delay and sequencer functions. For the second of these, we played the output on a small speaker and heard the repeated strum. For the third, we verified that the time delay and the amplitude scaling matched our hard-coded parameters.

Early in our testing, realized that most (64MB of 65MB) of our microcontroller’s memory was in SDRAM that wasn’t able to be allocated normally. After a while, we discovered a way to statically allocate memory into SDRAM on the Daisy Seed microcontroller: using the keyword “DSY_SDRAM_BSS” when initializing an array. This allowed our microcontroller to fit our delay and sequence buffers, each containing 2 s worth of samples, into memory.

We also have worked on our presentation slides for next week. We took images and video of some of our results as documentation of our progress and testing.

Schedule-wise, we are catching up and nearly finished. We are integrating a lot of our independently-creating components, and the resulting progress has been quite a relief. We will continue integrating this week, and I will finish the delay and sequencer code, accounting for some edge cases and more user input. I will also finish the pitch-shifting as soon as I can.

During capstone, I have honed skills such as task delegation, communication, considering end users, and prototyping code. However, I have also learned a very concrete skill: coding in C++. I started learning the basics using a couple short online video tutorials. I started by building a function that I could use to test the pitch-shifter. This allowed me to make progress while making a program that would be easy enough for me to get the hang of the language. I also have used a lot of online resources, such as the C++ documentation site and Stack Overflow, to answer questions in regards to implementation.

Posted on

Nick Status Report 4/19

At the start of the week, I worked on fixing the last major issue the interface code was having, and tested it with Chaitanya. Then, I tested inputs to the microcontroller from a function generator with Josie. Later in the week, I made an updated version of the interface code with all the implemented fixes for the major issues we were having, worked on the slides for the final report, and met with my group to test the combined interface and audio processing code on a breadboard prototype of the full circuit to check is functionality and test the output of the code for latency and that the audio processing code was accurately applied. After testing, we found a few small issues in the code, but nothing that prevented it from being mostly functional and providing the expected output. We seem to be slightly behind because of the PCB delay, but we will have time to implement that, fix the last few issues and have the full system completed and ready to test very soon. Next week, I will prepare for my presentation, fix the last few issues with the interface code, and meet with my group to implement the finished version of the pedal and test it.

As for what I individually learned, I first learned that hardware implementations run into many more issues than I expected. I learned how to design a schematic for hardware without any premade sections or guidance, as all of my previous classes related to this had either premade schematics or guidance with preselected components. I also learned how to find good hardware components and understand datasheets from spending so long looking through DigiKey for components that fit our design. Finally, I learned how to better understand and find issues with a software library, as the Daisy library is not fully functional and I spend a while looking through online references and forums to get the interface code working.

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.