Frantz’s Status Report for April 26

This Week’s Accomplishments:

This week, I finished the delay and sequencer, and I have nearly finished the real-time pitch shifter, with the exception of some debugging and edge-case testing.

As it turns out, using statically allocated memory is a lot easier than dynamic memory. Using pre-allocated memory buffers for storing the data is easier to implement, and it doesn’t take as many resources to run. With latency being such a concern, trading off space in favor of time is an easy decision. With window length down to 512 (instead of 2048), that also cuts our memory usage for the pitch-shifter. Nevertheless, with so much extra memory, this is not an issue.

After some debugging, the pitch-shifter does not segmentation fault anymore. Still, the output doesn’t match what it should be – I will check for implementation mistakes, testing with simple signals and moving on to actual guitar audio is going to help.

We will be finishing tomorrow.  We are almost there!

Chaitanya’s Status Report for April 26

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).

I got the PCB this week on Tuesday. After some initial testing with Nick’s test code, I decided that the PCB may not be fully functional. For the time being, we have shifted our attention to using the back up parts to get a working dev board implementation. This process involved placing components and resistors on dev boards and soldering them along with soldering wire connections. We have made significant progress and are looking to complete this tomorrow to do full system testing with the newer dev board options. Most of my time this week was spent in the HH labs and Tech Spark working with Nick to solder all components. 

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

We are not completely on-schedule, but it is still likely that we will have everything as desired by demo day. Our prototype was fully operational last week so the there should be minimal debugging for this implementation pivot. We should be hopefully wrapping up most implementation related tasks tomorrow and complete full system integration soon after.

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

With the demo on Thursday and video due Monday night, we are looking to have a demo-worthy project to showcase our hard work throughout the entire semester. Despite our numerous hardships throughout this project, we are aiming to have full-system integration done by tomorrow or Monday, so that we can put the finishing touches/get the appropriate measurements done for all documentation-related submissions that are due this upcoming week.

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.

Nick Status Report 4/26

This week, I had my presentation, so I prepared for that early in the week. Later, after Chaitanya tested the PCB and found that there was an issue, we decided to make a perf board implementation of the project for now to get something functional by Monday. We met a few times to solder the circuit and get a working implementation based on what we made for the breadboard prototype. I also fixed the last few issues the I/O code was having. We are almost done, just need to meet Sunday and early next week to finish putting the final version together and test everything, and then do the video, poster, and report. Next week, I have a final early in the week and at the end of the week, so I will have the least time to work, but will still meet with everyone to finish getting the perf board implementation completed and tested, and will do parts of the poster, video, and report.

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.

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.

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.

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.

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.

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.