Category: Xingran’s Status Reports

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 I have successfully implemented the audio in and out of our board.

I can input music through the XLR/ 1/4 inch jack to our board, sample it through ADC, process it so that one input channel is selected as both the L and R channel of output, and output it to the BM83 and finally hear it in my Bluetooth speaker or earphone.

Furthermore, I can control the ADC’s internal amplifier to adjust the gain on the signal. Currently I find that 8dB gain produces a reasonable volume level with clearest sound. Our on-board pre-amp was previously having about 0~2dB gain, it was faulty and Adam replaced it with a new one just recently, so I haven’t tested setting both our pre-amp circuit gain and the ADC gain to get the best possible overall gain level and music quality, I can do that next week.

As for signal quality, it is still quite noisy right now. I am using the rev 1 board which has some temporary soldering that could introduce a lot of noise, so we hope that noise will be less on our final board. I will be testing our new board next week, and integrate the UI module in so that the user could select the gain on the LCD screen, while our team will together try to increase the signal quality as much as we can.

This week as usual I went into the lab to facilitate testing the hardware, specifically programming the board to test the pre-amp signal out ability.

I have successfully setup the I2C control protocol with the ADC and can read data from our input channels. I will need more testing to determine the correctness and quality of the sampled digital signal.

For the Bluetooth module, the UART-to-USB converter we ordered a week ago arrived without noticing my apartment so I only got the package after I asked Quinn for tracking information this week. I later discovered that the module is smashed in transit and could not be used, so I had to order another one which is running late in delivery, and I have to wait until Monday to get it and test. There are a lot of uncontrollable forces in this but there are my faults too. I am learning the lesson and will be very proactive in tracking and examining the delivery every step along the way (sorry Quinn for bugging you :)) for any order from now on.

Next week I will finish the audio in and out ability or else we are in danger. I will keep everyone posted.

This week I was able to flash firmware updates to BM83 through OTA. I talked to the BM83 develop team over email and after rounds of debugging I could finally use their Android app as intended; I have also looked into many other programming and controlling options of BM83 along the way.

However, changing the operation modes in the firmware easily made BM83 stop connecting to the Android app, so I think the most reliable option is to have traditional UART update; I also found a GUI tool for sending/receiving UART commands/events to/from BM83, which I think should be our first step to connect BM83 to a speaker. Therefore, I purchased a USB-to-UART converter, so that I can largely follow the BM83 support documents in terms of how I program and config it.

While I am waiting for the converter to arrive, I tested our I2C control interface with the ADC. I can now read and write to the page select register in the ADC, which means that the hardware, I2C protocol and command formats are largely functional; by the time I post this I am still debugging writing and reading other control registers, but I believe it could be done soon.

Looking ahead, I will configure, pair, and connect BM83 to a Bluetooth speaker through the UART control interface with my computer (once the converter arrives). I will debug the ADC so that I can set its control registers, and then I will test its functions by feeding in a sine wave and check the output received by the microcontroller.

If these two things are done, I will officially be developing and testing our main audio path – streaming audio from the ADC input, through the microcontroller, to the BM83 module and then to the speaker.

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.

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.

This week I have finalized the microcontroller block diagram, though we had several component/interfaces changes this week and there were several intermediate versions. The microcontroller design document is also updated accordingly.

Microcontroller Program Design_0306

I have setup the STM32CubeIDE environment for developing the stm32f4 board, and looked at the examples and tools for setting up pins, controlling interrupts, etc..

I had made some feasibility studies including:

1.  Multiplexing 4 audio inputs at the same time. I made sure the ADC we use have TDM output capabilities, and though our board itself does not have software support for TDM protocol, with SPI interface we could read the data line in order, and get the 4 channels in order.
2. Using DMA for frequent and high bandwidth data transfers. I confirmed that DMA can support audio input through SPI, output through I2S, and LCD output through SPI.
3. Only using SRAM for DSP runtime data. I studied the flash on stm32 board and know that the endurance and latency of flash writes make it infeasible. So our run-time writable memory is confirmed to be only SRAM. (Sam will also mention this)

I did not finish defining all the interfaces and headers in program, because we had several component and interface changes which lead to overall software design change. There will hopefully be no more changes in the future and I will finish the following next week:

define code interfaces/function prototypes; test some of the protocols on the discovery board (I2C, SPI, UART).

This week I have defined the interface between the microcontroller and all other modules. I looked into the STM32F407VG microcontroller documents and BM83 documents, studied and listed all the control protocols needed, and completed a high level code design.

Microcontroller Program Design_0227

I have also order the discovery board.

While I am designing the code architecture, I added a few other things to my original schedule:

1.  organize the starter code and examples for the uC and BM83 module into a Github repository to start development
2.  find out the JTAG programming interface and booting sequence of these two modules
3.  discuss the DSP (high-level) algorithm workflow with Sam to confirm my current assumptions

I planned on finishing them but have not, so they will be for next week. Next week I also need to defined all the interfaces and headers for the code, and decide whether we want to use DMA.

This week I have finalized the trade and component selection of the power module and the microprocessor.

I have drafted the solution approach part of the proposal presentation.

I have combined all our teammates’ documents to make the proposal slides, and prepare for the presentation. (Please refer to proposal slides)

microcontroller comparison Solution Approach

---

Next week:

I will study the microprocessor and Bluetooth module development resources, and deliver a high-level design (possibly in terms of block diagram) of the software. I will purchase the microcontroller.