Brief Overview

Introduction

Professor Potter in ECE 582/682 has proposed the need for a wireless data acquisition device (DAQ) that is able to process audio signals from an array of wired microphones. The main application of this device is determining relative position information of objects located within the array. There is high interest in both military and academic research areas. Thus, the task at hand is to design and implement a prototype data acquisition device capable of recording multiple audio channels to a StarGate sensor node.

Brief Overview

A block diagram of the proposed design is show in Figure 1. Eight microphones will be biased and amplified. The gain for the amplifier will be user selectable. Each respective signal will be multiplexed to repeatedly sequentially select each of the eight signals. This form of multiplexing is time domain multiplexing (TDM). This means that eight signals are concentrated onto one line by alternating time slots. The single line out from the multiplexer will be low-pass filtered to prepare for analog to digital conversion (ADC). The ADC will convert the analog signals to digital format. The USB controller will read the value of the ADC and buffer it in memory. When the buffer is full, the USB controller will send packets of data to the StarGate node. Once the sampled data is in the StarGate node it may be decimated in order to match a user selectable sampling rate.

Requirements Specifications

The minimum requirements for the proposed data acquisition device as agreed upon by Team Yellow and Professor Potter are as follows:

· six channels

· 8000 Hz sampling rate on each channel

· Frequency response 20–4000 Hz using electret microphones

· 10 bit resolution on each channel

· pre-amplifiers with two or more selectable gains

· anti-aliasing filters

· powered from StarGate I/O interface (e.g., RS-232, USB, etc.)

· low-power “sleep” mode

· Reliable operation -10 to 40 degrees Celsius

· Design concept for weather-resistant package (for reporting only; construction

not required for prototype)

Further, the output must be compatible with one or more of the standards supported by Stargate: e.g., USB, RS-232, PCMCIA, compact flash, JTAG. Development costs may not exceed $100. (Product costs, per unit, for building multiple units are computed separately.)

Figure 1 - Bock Diagram

Detailed Component Overview

Microphones

[1]The electret condenser microphone (ECM) has two connecting wires. One is a ground and the other is the analog output voltage. The packaging can be seen in Figure 2. The ECM is connected to other devices in a fashion called “phantom biasing”, which can be seen in Figure 3. In this process, a capacitor and resistor are placed in parallel to each other between the ECM and the operational amplifier. The resistor is usually on the order of a few thousand ohms. This is connected to the voltage course for the circuit. On the other end of the resistor is the output of the analog signal coming from the ECM. At this junction, the capacitor is connected and leads away from the microphone as the overall system output voltage. This wire carries the signal representing the sound waves being measured. It is connected into the respective anti-aliasing filter. The end result of these resistors and capacitors is a small gain of roughly -3dBV and also a Total Harmonic Distortion (THD) of somewhere in the range of 1-10%. The ECM used in this project is the Panasonic P11969-ND. While maintaining a small package, the frequency range remains very wide at 20-16000 Hz. The typical operation voltage is [2]3V, with a maximum input voltage of 9V. The features of this microphone include a highly efficient electrical specification pressure type operating principal, low impedance (2.2KΩ), omni-directional back directivity, and high degree of reliability under adverse shock, vibration, and environmental tests. Also, the unit does not need a high voltage bias from the outside like ordinary condenser microphones.

Anti-Aliasing Filter

The output of the ECM is connected to an anti-aliasing filter. The purpose of the filter is to low pass filter the signal before sampling. This makes sure that there are no frequency components in the signal that are greater than 4000 Hz. This is the Nyquist frequency and will be the cutoff frequency of the filter. Analog filters will be used to keep cost down and because linear phase is not a requirement. An 8th-order elliptic filter was chosen because it is commonly used in anti-aliasing applications and it provides a sharp roll off of 82dB/dec. The elliptic filter properties include having the sharpest transition band and it is equiripple in both the passband and stopband. The Maxim MAX 7404 is an 8th-order lowpass elliptic filter. The cutoff frequency range for this chip is 1-10kHz, which is well within the required 4kHz. Power consumption is low; at 3V the filter draws 2mA.

Multiplexer

The multiplexer (MUX) that was used is a high-speed 8:1 analog multiplexer (MUX). The input of the multiplexer comes from the MAX 7404 anti-aliasing filter. The output of the multiplexer goes to the selectable gain. A 3-bit counter was used to systematically cycle through the eight channels. The 3-bit counter to the MUX will enable the signals to be TDM. Thus, the eight signals will be concatenated onto the same line using small time slots. The device chosen for this application is the Maxim MAX 4617. The reasons for selection are a high speed switching rate and the low price associated with it.

Selectable Gain

A requirement of the data acquisition device is to provide a user selectable gain for the microphones. After the signal is filtered, it is then amplified using an operational amplifier. This will be accomplished using the Analog Devices AD8330 operational amplifier. This amplifier has the ability to change gains based on the voltage level applied to one of its pins. This particular amplifier was selected mainly due to its ease of use. Unlike other similar devices it does not use a serial interface in order to set the gain and other options. Instead, it relies on using the voltage on two pins in order to determine the amount of gain to be used on the signal. The two pins provide the selectable gain. The first pin determines the base gain added (0-50 dB), and the second provides a multiplier ranging from 0 to 8. The design uses two dipswitches and two voltage ladders in order to deliver defined voltage levels to the device, thus giving the user easily selectable gain levels by setting the switches directly on the board. At some point later it may be possible to eliminate this part by adding some more circuitry to the USB microcontroller to set the gain. This would be accomplished by using flip-flops to provide different states for each respective switch position. However, it was determined that this would be too complex to fit in the proposed timeline. The team felt that dipswitches would be suitable as a proof of concept.

Analog to Digital Converter (ADC)

A successive approximation converter uses comparator and counting logic to perform the needed conversion. The advantage of using this type of ADC is it incorporates a fast sampling rate with the potential of having a high resolution. The resolution range of the successive approximation ADC is from 8 bits to 16 bits. The more bits used in the system, the slower the sampling rate. Specifically, the Analog Devices 1165 will be used. This ADC provides a resolution of 16 bits and up to 100kSps. Additionally, the AD1165 has a very low power consumption using only 400 microamperes. The chip provides 16-bit parallel output; this is convenient for connecting to the USB controller.

USB Controller

The USB Controller is a microprocessor that is used to convert the ADC output to USB packets that can be sent to the StarGate node. The selected controller is the Cypress AN2131Q. This controller was selected based on the recommendation of Dr. Ertin and because of the wealth of documentation associated with it. The USB endpoint type used to send the data will be bulk transfer. This is because the data does not need to be streamed in real time as long as a fixed delay is provided. The bulk transfer mode guarantees that each packet will be transmitted error free. The bulk transfer was chosen over the isochronous transfer because isochronous does not guarantee packet delivery and bulk transfer it is much easier and more commonly implemented. The controller was purchased as a surface mount chip with 80 pins. The team has found that by bending every other pin up, it is possible to solder wires to each pin and connect it to a breadboard.

The USB controller will provide many functions. First, it will stream audio packets to the StarGate node. This was accomplished by attaching the 16 bits of the ADC output to ports B and C of the controller. Ports B and C are each 8 bits. Thus, port B contains the high order byte and port C contains the low order byte of the ADC sample. The controller was programmed in 8051 assembly code to buffer 64 bytes of data, or 32 samples. Once the buffer is full, the controller sends a data packet to the StarGate node. The second function of the controller will be to provide an 8kHz clock to the MUX and the counter. This is possible because the controller’s internal clock runs at 24Mhz. Thus, it can execute many clock cycles and still toggle an output bit on port A at 8kHz by using timer 0, an internal timer on the controller.

Voltage Regulation

The components of the design require both a 5V and a 3.3V reference voltage. The Cypress USB controller and the filter both require 3.3V reference while the rest of the components require the 5V reference. The 5V voltage source comes from the USB cable; however, the LM2931 voltage regulator is used to ensure that the 5V is stable. The 5V will remain stable with input voltages as high as 14 volts and as low as 3.3 volts. The LM3940 was used for the 5V to 3.3V conversion.

StarGate

The StarGate node will be provided. The system specifications are available on Crossbow’s website. The input will come from the USB Controller. The StarGate will store the processed data in memory and able to wirelessly interface with other StarGate nodes using a PCMCIA network interface card. The user will be able to connect to the StarGate device via a RS-232 connection. Linux is the operating system on the StarGate.

Software is required to allow the hardware we have built to interface with the StarGate. There were three solutions to this problem. The first was to write a standard system driver. The second solution was to write an application based on the libusb Application Programmer’s Interface (API). The third option is to morph the first and second solutions to form a driver written with libusb. Libusb could be used in two options because the API is merely a specification on how to make calls directly to the kernel. It was determined that the best solution was to follow the first solution. Two arguments were made for choosing this option. The first argument was that a driver would provide a truly seamless solution to the end user. The second argument is that the driver would provide a high level of performance. Research showed that there was no strong support for simple Linux drivers that could interface with a Cypress chip. There were two options to overcome this hurdle. One was to design a driver from scratch, while option two was to search for available driver code that is used for other devices that could be re-engineered to interface with our Cypress chip. The fastest and most robust solution was determined to be the re-engineering of a scanner driver already present in the kernel source tree. This is permissible due to the GNU Public License (GPL), which allows for reuse of open source code as long as it is release back to the open source community.

There are two files associated with the scanner files, /usr/src/linux-2.4/drivers/usb/scanner.c and scanner.h. The header file is less important to us since it already provides all necessary declarations. These two files were re-written, shortening the code drastically. There was a lot of code in place to determine what hardware was connected and to do other tasks that make the driver much more user friendly to end-users of scanners.

Team Yellow wrote a driver that should work well with the newly developed hardware. However, during the testing and debugging phase of the software engineering, an error was found. The error was that our driver could not read a full 64KB block of data at a time. It would only operate properly for 1KB blocks of data. This error was traced through multiple files in the kernel source code without finding the cause of the error. In the best interest of the project with the given time constraints, it was determined other solutions should be sought after. A viable solution was using a USB Application Programmers Interface or API. Specifically, this software package is called libusb and is available for free under the GNU Lesser General Public License (LGPL). The LGPL allows for reuse of software written as long as any modifications that are made are returned to the open source community. The libusb software package can be downloaded from http://libusb.sourceforge.net.

Because a good portion of time was spent on the driver, and it operates much like libusb, it is worthwhile going over the driver’s basic functionality. In order for the data to be accurately transferred from the Cypress chip to the operating system, certain standards must be met within the driver. Specifically, the USB 1.1 standard for bulk transfer must be met. The action of the DAQ driver is closely related to that of a driver for a scanner. They both perform bulk-in transfers, from the device to the computer. The basic algorithm for the driver as follows. The driver will be initialized in the operating system. Next, it will open the devices for reading/writing. This is followed by the data transfers. Lastly, the device is closed, and the driver is removed from the operating system. It is not a very complicated process.