Team D0: BARI (Bluetooth Audio Rejiggering Instrument)
Just another Carnegie Mellon University: ECE Capstone Projects site
This week Sam delivered the Final Presentation during class. The team looked into the system’s noise, and found the source having to do with the BM83. Unfortunately, there is no time to resolve this issue. The audio path and UI code have been integrated, and DSP effects have been worked on.
The final efforts from the group include finalizing the video, poster, and final report.
Thanks for a great semester on behalf of Team D0!
This week I began integration of our full system, including debugging the hardware and software together.
A lot of effort was spent working with the new hardware, particularly establishing a strong physical connection with the LCD pins, learning to pair a speaker to the BM83, which required some soldering and re-soldering, exchanging dead wires, and removing bad connections.
Integration required a few attempts at debugging configuration issues since the audio path and UI had never been tested together. Eventually, with help from Xingran, I got this working. Now, the LCD is really dim, so I need to look into resolving this issue.
I conducted testing with a guitar as in input signal. There is latency of about 200ms (rough estimate), which I think is induced mostly by whatever Bluetooth codec we are using. Also, the signal is relatively distorted, with a significant amount of noise.
I successfully developed the delay effect, but noticed that it amplifies the noise due to the feedback loop.
Next steps are looking into the LCD display issue, implementing the EQ effect, and finalizing our video, poster, and report.
Here is quick video demo of playing guitar through BARI:
BARI BOX ASSEMBLY: This week, I used a hand drill to widen some of the critical mounting holes in the BARI Box, allowing it to be fully assembled for the first time.
AUDIO DEBUGGING: I also continued to work with Xingran to debug the noise issues with the BARI audio channels. Please refer to the #d0-bari channel in Slack, where I gave a full report on our findings and what is / is not possible going forward. In short, we’ve found a difficult-to-mitigate noise source due to power rail noise injection from the BM83. Several mitigation strategies are possible to make the BARI concept functional in the long term, but it’s not possible to implement these strategies with the time and resources available to us.
Unfortunately, due to contact with a person who tested positive for COVID-19, I have been instructed to quarantine and remain away from campus. This will make it difficult for me to assist with the production of the final video demo, but I plan to help out with editing and compiling the written report in the next few days.
This week I have debugged the audio quality, and integrated our full software system code.
For the audio quality, what I measure in the digital domain (the samples of the ADC) matches the analog signal before the ADC observed on the oscilloscope. Therefore, I decided to check that the audio sent to the BM83 matches the ADC samples. I attempted to use the DAC + 3.5mm jack on the discovery board to hear the sound on the I2S bus to the BM83, but it turns out that we need an extra master clock in sync with the I2S clock in order for the DAC to work. It is not impossible but would bring extra complexities to our integration schedule, so I just plotted the data sent out from the stm32 instead. It turns out that sometimes my double buffering scheme (referencing a basic implementation found in tutorials) could sometimes create discontinuities in the output signal, because the transmit DMA is not always avoiding the buffer that is being actively written to. Therefore, I designed another double buffering scheme using some extra variables and status flags, and I could now validate that our shifted out audio data matches our input data, without discontinuities. The audio quality after this enhancement is slightly better in my opinion but we did not formally verify that.
As for the noise before the ADC in the analog domain, I helped Adam debug in the lab and he has posted the results to Slack.
I have also integrated the UI code from Sam into my main audio signal path code, and I will be working/debugging with Sam in the next few days as he test the full system. I have refactored the code so that it follows good style and provides readability, which is going to help us reduce mistakes as we make small changes from now on.
Throughout the semester there has been hard times, but also times when I enjoy the great joy of finally getting a component to work, especially that second when I hear one of my favorite songs (albeit bad quality at that time) successfully streamed through our board to my Bluetooth earbuds.
I am not a typical, expert embedded systems person and I have not had much experience with analog and signals before. But I did want to play with some cool stuff outside my usual ECE areas so I was very happy to work with Adam and Sam who both have taught me a lot along the way. I have learned a LOT that could not be learned unless I do this capstone project.
Thanks, my teammates, and my TAs and professors, for an unforgettable semester!
Happy graduation : )
This week my main task is debugging the audio signal quality.
I have plotted the audio data sampled by the ADC, with no audio or sine wave audio. It turns out that we have a larger than acceptable noise which is constantly affecting the signal.
(y axis: ADC readings, 3.3V corresponds to 32767 (uint16 max))
With some probing in the lab and with the new pre-amp, Adam confirms in the lab that the signal before the ADC has only a little noise introduced. So I focus on checking sampling errors or Bluetooth transmission errors in the digital domain, since that is where most of the noise is introduced. I am setting up a program to stream the ADC sampled audio onto the I2S bus on my stm32 discovery board, so that I can directly hear it through the on board DAC; in this way I can isolate whether the ADC or the BT module is faulting. This is what I will report on next week.
I have also updated the software diagram, and performed the quantitative tests for ADC sampling, signal latency, and BT range that we will present in our final presentation.
(Noooo! Most of my time I am exhausted in the sea of 3~4 circuit boards and jumper connections and I feel I am growing succinct/lazy on status reports :O )
This week we continued work on the signal path and UI. We started using the new pre-amp on Rev2, observing a large increase in quality. Due to the current chip shortage, our manufacturer was unable to provide us with essential components we needed for a complete Rev2 assembly. As a workaround, we decided to pass the final design’s signal through this pre-amp and then jumping the signal over to one of the Rev1 boards. There is still some noise that appears to be from the ADC, which is being looked into.
The UI is in a usable state, with meaningful variables able to be adjusted, and full control of our input devices (switch, button, encoder).
As a team we also worked on the final presentation, which Sam will deliver next week.
Next week we will wrap up validation, implement our updated MVP DSP effects, integrate the UI and signal path, and work on overall signal path quality. We will also make our video.
Here is our updated schedule:
For a little bit of fun, here is the guts of our beautiful BARI box:
This week I worked on the UI. I have successfully included global control variables for parameters such as channel enables and gain. Everything is controlled by the rotary encoder, button, and a programmable footswitch. As we add new effects or features, I can easily add new menus and variables given my modular infrastructure.
Tomorrow I will prepare for the final presentation, which I will deliver on Monday or Wednesday. Before then I need to update some slides and include information on UI validation.
Next week I will work on implementing at least delay and EQ, as well as helping Xingran with integration between the UI and audio signal path. I am currently on schedule, but we have a lot of work to do before the end!
Below is a short video demonstrating the UI:
REV 2 BUILD & PRE-AMP CHARACTERIZATION: This week, I partially assembled our newly-arrived Rev 2 boards, building out a complete pre-amp channel. This allowed me to finally characterize the BARI pre-amp for gain flatness and THD, though the limited test equipment available prevented me from characterizing it to a high degree of precision. For details, see the final presentation slides to be presented on Mon/Weds.
A representative curve can be seen below, demonstrating the input and output signals and spectra for a ~200 mV, 1 kHz signal. A Blackman window is used, improving the spectrum dynamic range as compared to last week.
I am currently working with Xingran to debug sources of noise in the analog/digital domains and devise appropriate mitigation strategies. This work will continue through the next week, in parallel to other integration efforts.