Kevin

Done this week

This week, I looked through numerous examples of source code for beamformers and attempted to adapt them to our use.  I also spent a large amount of time reading through a large portion of text from Professor Sullivan’s Adaptive Nulling textbook.  The textbook helped connect a number of conceptual aspects that I did not clearly understand previously, which has led me to decide to write the beamformer from scratch.  

 

Breakdown the exact parts of the Beamformer I am in the process of writing:

• INPUT:
  • taking in a 4-channel input (each channel buffer is uint16_t[128])

• Build Sample Matrix
  • We want to get a 9-tap filter for each input channel (picked odd-number so there is a center of matrix)
  • Build a matrix of 9 time samples from each input channel and put into vertical matrix
    • [x1(n),x2(n),x3(n),x4(n),x1(n-1),x2(n-1),x3(n-1),x4(n-1), …, x4(n-9)]
    • 9*4 = 36 degrees of freedom
• Find covariance Matrix
  • QR decomposition of sample matrix (I have C code for this)
  • R will give us the Covariance Matrix (80×80 matrix)
• Multiply Inverse of covariance matrix with steering vector.  
  • Steering Vector: [0,0,0,…,0,x1(n-4),x2(n-4),x3(n-4),x4(n-4),0,…,0]
  • 36×1 Matrix
  • The result gives you the coefficients for each of the tapped-delay lines (FIR filters)
• Now take each channel output and put through FIR filter designed in previous step
• Sum up results of each channel

 

I am currently working on a matlab implementation of this specific frost-beamformer so that I can run tests to pick exact specs such as number of taps,samples, etc.  This will also help verify that the algorithms I am running are working. I am also going to verify this with Professor Sullivan during Monday’s lab.

Bobbie

Done this week

This week I spent many hours messing with getting four-channel audio from the microphones working. While four-channel output worked fine with some white noise on channels 3 and 4, I was unable to get any input at all from any of our microphones. This set off a long debugging process:

1. Check to see that the microphones were working on my computer (they were)
2. Check to see that the microphones worked with all the splitters we were using (they did)
3. Check to see that it is actually a lack of input and not some disconnect between the input and the output (it was)
   1. This was done using a variation on the PeakMeter audio example.
4. Check to see all the code was configured correctly
   1. I actually caught a couple spots where the code was taking line in instead of mic, but fixing this still did not give me proper input
5. Check the documentation for assembling the quad channel Teensy: https://forum.pjrc.com/threads/41371-Quad-channel-output-on-Teensy-3-6/
   1. I actually caught a capacitor which should have been removed but had not been. Removing it also did not fix it.
   2. While messing with this, I also broke some of the solder connections which had been fine before, so I had to resolder those.

 

At this point I ran out of ideas and decided to try plugging things in and out and running old code in hopes that something interesting would happen. In fact, two things did:

1. I was able to get noise through the system by half-plugging in a mic jack and twisting it against the port.
   1. This noise registered on PeakMeter, indicating that the input noise was in fact reaching the board.
   2. But, when I plugged in the mic fully, nothing happened.
2. I was able to get complete audio (!) through the system by half-plugging in an audio source (my computer) into the headphone/mic splitter. Beautiful perfect clean audio playing from the speakers.
   1. Nothing good came out of this actually. On testing I found that it only worked with the headphone/mic splitter in particular, which was suspicious. It took a while to figure out, but eventually I narrowed it down to a quirk of the splitter where half-plugging in the mic would send the signal directly to the headphone side, bypassing the board entirely. So really, this was useless.
3. I found that on writing to SD card, the speakers would play a weird tone.
   1. I interpreted this as meaning that there was some short between some SPI-related pins and the ones used to transmit microphone data.
   2. On the diagram, RX (mic input) and SCLK (SPI clock) are in fact right next to each other (towards the top right of the diagram)

 

Because of this latest discovery I have resigned myself to desoldering the boards entirely and doing it again, hopefully cleaner this time. I will do this tomorrow (Sunday).

 

I have also acquired Lexan for use with the microphones. The lapel mics are quite small and light so this will be easy. These have not yet been assembled because of the problems getting input mentioned above

Goals for next week

• Resolder these stupid boards and get input working (pls)
• Test SDW-MWF Teensy Audio code
• Mount the mics

 

Sean

Done this week

This week I soldered the second audio shield onto the board for four-channel audio input/output. Unfortunately, they aren’t working. Output works fine on all channels, but Input is noisy and unreliable at best. Hopefully bobbies debugging skills are better than mine and he can get to the bottom of this.

 

I also rewrote audio recording code to work with four-channel input. The main challenge with this was changing to using multiple audio queues to hold all the data. Going forward, processing four blocks of audio simultaneously may possibly issues that don’t come up with a single buffer.

Goals for next week

Next week, I hope to fix the input on the board. We need to get this fixed in order to be able to use our algorithms as intended.

 

Also, I plan to help Kevin finish up with his beamforming code, adding the Arduino- and Teensy-specific components to his C++ code.