Skip to content Skip to navigation

Connexions

You are here: Home » Content » Labview Implementation of 2D Array Delay and Sum Beamformer

Navigation

Lenses

What is a lens?

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

This content is ...

Affiliated with (What does "Affiliated with" mean?)

This content is either by members of the organizations listed or about topics related to the organizations listed. Click each link to see a list of all content affiliated with the organization.
  • Rice University ELEC 301 Projects

    This module is included inLens: Rice University ELEC 301 Project Lens
    By: Rice University ELEC 301As a part of collection: "ELEC 301 Projects Fall 2005"

    Click the "Rice University ELEC 301 Projects" link to see all content affiliated with them.

  • Rice Digital Scholarship

    This module is included in aLens by: Digital Scholarship at Rice UniversityAs a part of collection: "ELEC 301 Projects Fall 2005"

    Click the "Rice Digital Scholarship" link to see all content affiliated with them.

Also in these lenses

  • Lens for Engineering

    This module is included inLens: Lens for Engineering
    By: Sidney BurrusAs a part of collection: "ELEC 301 Projects Fall 2005"

    Click the "Lens for Engineering" link to see all content selected in this lens.

Recently Viewed

This feature requires Javascript to be enabled.
 

Labview Implementation of 2D Array Delay and Sum Beamformer

Module by: Sara Joiner, Jeanne Guillory, Ray Hwong, Austin Bratton. E-mail the authors

Summary: This module describes our implementation in Labview of an eight microphone, two-dimensional array beamformer. Due to the relatively small size of the beamformer, it was implemented using a delay and sum algorithm in the time domain.

Introduction

Our project involves using a two-dimensional array of microphones to determine the direction from which a mystery signal comes. This involves taking data from the microphones, doing analysis of the data, and then outputting the results. The second step we chose to implement in Labview. In order to interface correctly with the DAQ card we had available, we used Labview 5.1.

The labview implementation of our project involved several stages: First, we wrote a vi designed to get the input from the microphones by sampling the eight inputs to the DAQ card, and separate the resulting data into eight arrays, each holding a digitized signal. We then upsampled each array (using a separate vi for that purpose) and passed the upsampled signals to the main analysis vi.

The main analysis vi tests three of the signals by taking two of them and testing them individually against the third. This test involves delaying the two signals and taking the norm of the delayed signal and the third signal. Each norm is collected in an array, from which the max norm -- correspondent to the correct delay between the two signals -- can be found.

If we know the correct delays between three signals, we can do some mathematics (explained in greater depth in the section on the delay generation vi) and derive the angles the signal is coming from.

Note:

As a two-dimensional array has the ability to discern a point in three-dimensional space, there are two angles found here: theta, the angle along the xy plane, and phi, the angle relative to the z axis.

From the angles found, we can then calculate the appropriate delays to be applied to the other five signals. Finally, we take all eight signals, delay them appropriately, and add them together to get our final result. This is known as delay and sum beamforming.

Waveform Generation VI

Most of the work here was done for us already, through Labview's Generate Waveforms VI, a module that, given certain information about an attached DAQ card, sampling rate, time to be sampled, etc., will seek out that DAQ card, sample the requested channels, and return the results in a two-dimensional array of doubles, where one dimension corresponds to the sample of the signal at one particular point in time, and the other to which channel sampled from.

Figure 1: VI we created to sample the microphones and upsample the resulting arrays
Waveform Generation VI
Waveform Generation VI (getsig.bmp)

Our module took the data from said VI and separated it into eight one-dimensional arrays, one for each microphone. (This was an essential step, as many of the array analysis functions that we wished to use would only work with one-dimensional arrays.) Using our Upsampling VI (discussed below), we then upsampled the signals, lowpass filtered them to interpolate the signal, and set the eight filtered and upsampled signals as the output of this VI. This module takes as an input N, the amount by which the signals should be upsampled, and an input fs, the sampling frequency.

Upsampling VI

From the beginning, we knew that there would be restricted sampling rate of the DAQ card, and the buffer would be effectively decreased by a factor of eight for any one signal (since the data from all eight signals comes into the same buffer). Whatever sampling rate was left would meet the most basic Nyquist requirements and avoid aliasing in that fashion; however, the resultant signal was unlikely to possess much resolution beyond that. Thus, upsampling would be a necessity.

We initially searched Labview itself for a premade upsampling VI, presuming that one would exist, as it is a fairly common signal processing algorithm. However, we were unable to find one and so set about creating a module that would do the job. Our module takes as inputs the signal (array of points) to be upsampled and N, the amount the signal was to be upsampled, and passes as an output the upsampled signal.

Figure 2: Sub-VI used to upsample a signal
Upsampling VI
Upsampling VI (ups.bmp)

Following upsampling theory discussed in class (ELEC 301: Signals and Systems), the first step to our upsampler was to zeropad, that is, add zeros in between each point on the signal being upsampled. Instead of attempting to implement a dynamic array, this was accomplished by creating a new array of the appropriate length (N times the length of the original array, where N is the amount the signal is being upsampled) and using a for loop to place the original signal elements into the new array spaced N points apart.

This enlarged array of data is then passed back to the Waveform Generation VI where it is lowpass filtered in order to fill in (interpolate) the new zeroed out positions, and passed onward as an output of the Waveform Generation VI. The filter used in this operation is the Equi-Ripple FIR low pass filter.

Delay Generation VI

This VI does the bulk of the mathematical analysis of the input signals. It takes as inputs the two delays between microphones one and two, and one and four (derived from the calculations of max norms in the Main Analysis VI) and outputs an array that contains theta, phi, and the corresponding delays for the seven microphones (the delay of the first microphone is automatically set to zero). In all cases, the delays are scaled to correspond to the number of indexes the corresponding signal should be shifted, instead of the actual real-time delay. (As we cannot shift a signal by fractional indexes.)

d12 = k12 / (fs * N);
d14 = k14 / (fs * N);
phi = acos( sqrt (v^2 * (d12 ^ 2 + d14 ^ 2) ) / d ) * sign (d12 * d14);
theta = atan (d14 / d12);
d13 = d12 * 2;
d16 = d14 * 2;
d18 = d13 + d16;
d15 = d13 + d14;
d17 = d16 + d12;

The first part of the above code is calculates the angles based on the spatial relations between the three microphones (microphone 1, used, as we said before, as the origin, and microphones 2 and 4, which can be found directly adjacent to microphone 1 in both directions). As you can see, it is fairly simple geometry, complicated primarily by the scaling necessary to match the 'k' values (integer values used to iterate the for loop) to their corresponding 'd' value (actual delay in time).

The second part of the code uses the angles mentioned above to calculate the delay values, although again due to the regular nature of our array, it is possible to calculate only two of the delays outright and extrapolate the rest of the delays from those two. (Which is indeed what we have done in an effort to reduce calculations and make the algorithm more efficient.)

The final part of the code, not shown in the code above but which can be seen in the function node in the figure below, involves the recipropcal of those first two lines; that is, rescaling all the 'd' values found to 'k' values that can actually be used when shifting the signals prior to adding them together.

Figure 3: Sub-VI that, given the values 'k12' and 'k14', will generate the shifts (in indices) of the seven microphones (with the shift of microphone 1 assumed to be zero) and the angles theta and phi that the signal came from.
Delay Generation VI
Delay Generation VI (gen_a_shift.bmp)

Main Analysis VI

This is our top-end module, where all the modules mentioned in the previous section are brought together in the same vi and linked together in the proper ways so as to create a working project.

Figure 4: The culmination of our struggles with Labview 5.1, our top-end module which does ... well ... everything.
Main Analysis VI
Main Analysis VI (mainanal.bmp)

First, not unexpectedly, there is a call to the Waveform Generation VI, which provides us with our collected and upsampled signals. From that sub-VI, the signals from microphones 1, 2, and 4 are taken, microphones 1 and 2 passed to one for loop and 1 and 4 passed to the other. Within the for loop, as mentioned before, one signal is shifted relative to the other, and the norm taken, for all delay values possible. The result of this is concatenated into an array, the maximum norm found, and from the location of the maximum norm, the value of the delay, or as close as we can get with the sampling resolution we have.

These shift values (the integer index corresponding to as close as we can get to the ideal time delay) are passed to the Delay Generation VI, which then returns an array of values. The theta and pi values function as outputs to the front panel, and then the delay (shift) values are used to set the necessary shift for their corresponding microphone. Finally, the shifted output arrays are all summed (using a for loop, as a point by point summing module also seemed to be among those useful things not premade in Labview 5.1), and the output of the for loop, the array that is the sum of all the previous ones, is then attached to a waveform graph, also on the front panel.

Figure 5: As the titles state, the upper waveform is that of the first signal (unmodified in any way), and the second that of the final, delayed and summed signal. Note how the latter signal is somewhat smoother and the noise level reduced in comparison to the signal itself (a series of claps). The two numbers at the bottom correspond to the computer's calculation of what direction the signal is coming from.
An Example Result
An Example Result (itworks4_edit.bmp)

Note:

Phi is measured such that straight up is at zero, along the xy plane at 90 degrees. Theta is measured with the "bottom" of the array (although it can of course be reoriented as the user pleases), that is, the negative y direction, as zero degrees. The signs of the angles indicate the direction of propagation of the wave, and are thus opposite to conventional intuition, and the sign of phi is, of course, impossible to determine with any degree of accuracy due to the up-down ambiguity inherent in a two-dimensional array.

Success! (For a deeper exploration of our results, please continue to the results module

Content actions

Download module as:

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks