Two weeks ago, the entire focus was on writing our design document. This was an extension to our design presentation, and consumed most of our time that week. It’s attached below if you want to check it out!
Our Rev 1 PCB was delivered this past week. Adam and Xingran wrote up a test bring up plan and proceeded to test the boards in Ansys Hall. See Adam’s post for more details, but while some modules worked as expected, there were some set backs. However, this was expected, and was one reason our plan includes Rev 1 as a demo board.
Bring up of low software is now the focus for the group, especially getting the BM83 Bluetooth module to work, and creating a UI. Once we can get an audio signal to a speaker, that will be a huge success, and it’ll be even better if the user has basic control over parameters. As such, Sam is halting work on DSP effects and Xingran will be focusing on work with the BM83.
While we are deviating from our original schedule, the included slack time inhibits any real danger to our progress. The next few weeks will be pivotal to getting a MVP product, but once that is completed, the additional features can be added more easily.
The past two weeks, I have focused on our MVP DSP effects of chorus, delay, and EQ. I have successfully prototyped delay and EQ with user-controlled parameters that shape the sound according to our design spec. Chorus is very close, but I am running into a bug where there is a crackling sound introduced with the audio. I suspect this might be a feature induced by block processing that I have to find a way to work around. If I can’t get it working, I will reach out to Tom Sullivan or maybe Ryan for some guidance.
I provided a demo of the MVP effects to my team last Monday, and received positive feedback. During our Monday sync-up, Tom suggested wah-wah as an additional effect if we have, especially I have a mid-peak filter working. The implementation would be as simple as sweeping the center frequency of the filter.
I am behind on the STM32 implementation of effects, but I am still optimistic I can port my MATLAB code to C quickly.
For this next week I am shifting my focus from DSP effects to UI design. I will start with a wireframe and then from there write code for the menu layout, assuming I am provided high-level functions such as write_to_lcd(char[] str). This is a change in our schedule, but one we deem as more essential to getting a working product than the MVP effects.
Below I have included an audio file with our custom delay effect added with the following settings:
Last week I have written code on the discovery board to control the I2C and I2S interface, as well as DMA. I was able to stream audio from the internal flash memory through I2S to the built-in DAC (controlled through I2C), and hear the sound output from the 3.5mm jack. The whole streaming is done by DMA and I can customize the DMA callback function to adjust buffer pointer etc. so that the audio is streamed continuously.
This week, I configured all the pins and clocks and interface settings for our own board’s microcontroller; I and Adam tested Rev 1 together and were able to program and debug the board. I was able to toggle GPIO output, output master clock to the ADC, and control the Digipot through the I2C bus. Controlling (I2C) and streaming from (I2S) the ADC is yet to be tested when we have a functional ADC on board. We figured out a way to program and control the BM83 Bluetooth module very easily through Over-the-Air firmware updates in the available Android app, but we were only able to get BM83 powered on and connect to it; yet to fix an error in OTA programming.
Looking ahead, the priority is to make sure the sound signal path functions correctly. Specifically, I will focus on getting control over BM83 and connect it to a Bluetooth speaker, then stream audio from microcontroller flash through I2S to BM83 and then to the speaker. I will then rendezvous with Adam on the working ADC board and try getting audio input from the ADC (also through I2S). If these two parts work, then we can get audio in and out of our system which is a big step towards MVP.
My plan for next week is to get the BM83 part working.
REV 1 PCB BRINGUP: Our PCB boards for Rev 1 (pictured below) arrived Tuesday, and the components to populate them arrived mid-day Wednesday. Before the arrival of these parts, I compiled a several page PCB Bringup Procedure (part of the larger BARI Test Procedure) to describe the final electrical manufacturing and test of these boards. After the parts arrived, this document guided me as I assembled our first testboard (“Bernice”) and worked with Xingran to validate different sub-sections of the design.
Two significant setbacks occurred in this process: First, JLCPCB failed to populate many of the SMD passives on our board. (They have since offered a refund for those components.) Second, I made a series of soldering mistakes that rendered Bernice’s ADC unusable. Nevertheless, we managed to bring up the STM32 microprocessor, communicate on the I2C bus, and verify that the BM83 is functional.
BARI BOX: Simultaneously, I started the design of the BARI BOX, the mechanical enclosure which will enclose the BARI PCB and provide a mounting place for all of its components. I will refrain from posting an image of the WiP BARI BOX so as to not spoil the surprise ~~~
In response to the glitches above, I’ve formulated a revised hardware plan that calls for creating a second Rev 1 (“Alexey”) in the coming week, using newly-ordered components and revised soldering procedures. Rev 2 fabrication will be somewhat delayed relative to our schedule to allow for sufficient testing on Alexey. My current target is to order the Rev 2 boards by 4/8 (and receive them by 4/18).
This week Adam gave our design presentation, and we got to see how other groups have refined their project. We met on Friday to update each other on progress, discuss Rev1 budget details, and help debug the SPI protocol that Xingran was implementing.
We faced a risk in that the intended PCB manufacturer charged more than we expected and had an estimated arrival of much later than we deemed acceptable. As a result, Adam found a new manufacture that would be cheaper and offer much quicker delivery. The downside is that we will have to hand-solder some of the components with this service. However, the savings in cost (1/2 the cost) and shipping time (a week or two at most) justify this small setback. Another decision was to buy two Rev1 boards since the overall cost of fabrication would be the same with our supplier. This incurs additional component cost, but we agreed it would be better for risk mitigation to have two boards anyways.
Adam has agreed to take a larger role in the design document next week to give Sam and Xingran more time to work on software development since both are a little behind schedule. However, we are still mostly on track, especially given our ample slack time.
Next week we will work on the design document during class time, Adam will work on the mechanical enclosure, Sam will continue MATLAB prototypes and begin working on STM32 algorithm implementation, and Xingran will continue low level software bring up.
This week I focused on prototyping our MVP effects (delay, chorus, 3-band EQ) in MATLAB. In particular, I tried to write the algorithms such that they can be ported to the microcontroller environment easily. This includes strategies such as mocking block processing by using input buffers that go through for loops.
I made good progress with chorus, setting up a superimposition of delayed copies of an input signal with delays set by a “LFO.” In its current development this LFO is more of a triangular wave than a smooth sin wave since I have not implemented interpolation between discrete points. I have not settled on how many copies of the signal to overlay. Currently the effect is audible, but it’s not very strong.
I did more research on 3-band EQ’s and instead of typical LPFs and HPFs, low shelf and high shelf filters are used. I have not implemented my 3 filters yet, but I am thinking of starting my using the specs in this report. This includes a low shelf with a center frequency of 200Hz, a band pass filter with Q = 1 and a center frequency of 1kHz, and a high shelf with a center frequency of 5kHz.
I will model the delay algorithm using this reference from Analog Devices. Their algorithm is in line with what I was thinking to do, and it’s good to see an industry standard reference.
Unfortunately I am still behind on prototyping the MVP effects in MATLAB. I think that writing them in a way such that they can be written on the STM32 environment quickly will help save time during the actual implementation, so I am not too worried. While I was hoping to give a demo of the MVP effects last Friday, I will have to push off the demo to some time this week.
I worked with Adam to finalize our purchases for Rev1 and created lists for Amazon and DigiKey, filling out the form for the Amazon order.
Next week I am hoping to complete the MATLAB prototyping and begin writing some framework code (buffers, looping structures, etc.) for implementing the effects on the STM32. In addition, I will work with Xingran to develop the outline for the user interface menus.
Check out the audio file to hear a chorus effect in action! This is an excerpt from a recording of the guitar part to Sondheim’s Assassins musical that I did for the school of drama back in January.
This week I have worked for many hours to implement and test the SPI interface on the stm32 discovery board. I have setup an Arduino Uno to communicate with the stm32 board via SPI with stm32 being the master, and verified the stm32’s ability to send and receive individual bytes, both in synchronous mode and in interrupt mode. However, I did not have time to implement stream send and receive via DMA.
I have encountered an issue with corrupted LSB in interrupt receive mode, and struggled to debug for a very long time. With the help of my teammates I was able to narrow down the bug and found the solution (lower the APB clock speed and increase the GPIO speed) to this known issue online.
I was not able to test all of the peripherals and define the function prototypes of our system as planned. Implementing SPI takes a lot more time than we could afford, but it is also the most important and complicated protocol for the microcontroller. Protocols like I2C can build on the knowledge gained in implementing SPI, and the complicated UI interface is not absolutely necessary for the MVP. So I am still waiting to see how much I can do next week to decide whether we want to make major adjustments to our schedule and/or MVP.
Next week I plan to finish: implementing SPI with DMA and time division multiplexing, and I2C.
REV 1 PCB ORDER: As planned from the previous week’s status update, I completed the Rev 1 PCB layout this week and placed an order to have it fabricated. This consumed the majority of my time.
After some negotiation with PCB fabs, I elected to switch from PCBWAY to JLCPCB because of the high cost ($200) and lead time (>25 days) offered by PCBWAY in comparison to JLCPCB (< $50 and ~ 1 week). The significant trade-off was that JLCPCB only stocks a subset of the components we need, so I will have to do additional hand assembly at TechSpark later in the semester. Even including this hurdle, JLCPCB still compares favorably to PCBWAY.
With help from Sam, I also placed a Digikey order for all of the on-chip and off-chip components that will be needed to fabricate Rev 1. Our target remains to receive the board during the week of 3/22/2021.
The final board layout is shown below. Overall dimensions are 2.6″ by 3.8″.
DESIGN REVIEW PRESENTATION: I delivered the design review presentation on the behalf of our group. I created an updated hardware block diagram (shown below) to represent our revised hardware flow, and worked with Sam and Xingran to fairly present the items which they are working on. I received overall positive feedback. The one item of concern was the risk associated with our PCB and integration. However, I believe that we have responsibly mitigated this risk through our accelerated Rev 1 schedule and the time it leaves for integration in late March – early May.
During the coming week, I will take the lead on preparing our design report as my teammates focus on other technical areas of the project, while also beginning the mechanical design, as planned in our master schedule.
This week we reviewed Adam’s schematic, adding labels/clarifications where necessary and correcting errors. We received feedback from Ryan to include a clipping indicator, which we added to our design specification to be implemented in software. Ryan also suggested a audio-specific ADC, which we decided to use. In addition, we determined that the SPI protocol would be a better choice than the 6800 parallel interface for our LCD display.
We met up to work on the design presentation slide deck, splitting up development of the content on the slides for Adam to present.
Sam and Xingran discussed the implementation of the DSP effects, and due to the limited SRAM of the microcontroller, decided to switch from reverb to delay as an MVP effect. We adjusted the schedule to give Sam another week to work on prototyping the MVP effects in MATLAB
We worked on the overall software block diagram to supplement our hardware block diagram to prepare for the design presentation.
Adam will give a dry run of his design presentation on Sunday to Xingran and Sam to receive feedback for the actual presentation Monday/Wednesday.
We will be ready to order our Rev1 board by Wednesday!
This week I focused on researching algorithms for our MVP effects, EQ, reverb, and chorus. The standard way to implement EQ is by having a filter for each band, and applying an amount of gain to each filter, to shape the frequency response. This should be simple to implement, requiring filter coefficients, and buffers of inputs and outputs of the signal. Chorus is implemented with overlaying copies of a signal with variable delays controlled by LFO’s. In essence it should should like a “chorus” of singers or instruments playing all at the same time, with slight phase variations. This will require storing some inputs and outputs, past what we are storing in our DMA input and output buffers. I researched reverb, and after a lot of research into different implementations (mostly Schroder based reverbs such as “Freeverb”), it seems that for a versatile reverb with a large delay time, we run into issues with storing inputs and outputs. To store 1 second of inputs and outputs, required for a 1 second reverb-time, we would use just about all of our available SRAM. After some consideration, the team and I decided that going for delay would be a better option. A 1 second delay is practical, whereas a 1 second reverb time is a bit low. Delay is an IIR system that involved a feedback loop with a gain less than 1.
I did not implement any MVP effects in MATLAB, so we updated the schedule to give me another week to actually implement the effects. Prototyping the effects properly will save time in the end as we try to port the effects over to the STM32.
While researching the MVP effects, I looked into the memory usage of the effects, and talked with Xingran about implementation decisions- we ultimately decided on double input and output buffers served by DMA. We expect a processing latency of about 12ms.
Since we changed the schedule, my focus will be on implementing our MVP effects in MATLAB and providing the team a demo on Friday.
