You are on page 1of 22

AUDIO TRANSFER USING BLUETOOTH (MOBILE CHOONS PART DEUX) By Rory Shea Rich Finn ECE 345: Senior

Design TA: Julio Urbina April 30, 2002 Project #44

ii ABSTRACT The goal of this project was to transmit hi-fidelity digital audio wirelessly using the Bluetooth specification. The ability to transmit CD quality audio wirelessly would be very beneficial because it eliminates the need for costly speaker wire in car and home audio environments. It could also eliminate the need for wired headsets on portable audio devices. Our group plans on streaming audio samples using Motorola Bluetooth cards and the Digianswer Bluetooth Software Suite. We also plan on exploring techniques to compensate for slow transfer rates. One of these techniques is called channel bonding, which enables two mediums to be bonded together in order to increase their effective transfer rate. This as well as other methods will be explored. We worked with group #45 on this project.

iii TABLE OF CONTENTS


Audio Transfer Using Bluetooth.......................................................................................................................i (Mobile Choons Part Deux)...............................................................................................................................i

iv 1.INTRODUCTION 1.1 Objective This project has two major phases to it. The first phase is designed to be a continuation of the Mobile Choons project by Jeff Vyduna, John Hebda, and Bill Ho done last semester. The original goal of this project is to utilize Bluetooth technology to send music wirelessly throughout a vehicle. Currently, Bluetooth technology has been utilized to transmit voice signals in such applications as a carcell phone wireless connection. The ability to transmit higher quality audio could lead to further advancements in wireless communications such as an entire car audio system consisting of no wires. The Bluetooth V1.1 specifications are specific and detail a low cost, low power wireless network for use within 30 feet between devices. It utilizes a frequency hopping spread spectrum (FHSS) modulation in the unlicensed 2.4 GHz ISM band, and is capable of a raw data rate of 1Mbps. The previous group planned to use audio compression to transmit the signal and then used the receiver to decompress the signal. Unfortunately, many roadblocks and time constraints forced the group to alter their scope considerably. We plan to take a more humble approach towards the goal, starting small and building on success. The Mobile Choons have left us with a solid foundation to build upon. The second phase of our project will focus on the exploration of a new technique called channel bonding. This technique has been used with Ethernet cards and involves connecting multiple cards in parallel to create faster data transfer. As stated above, Bluetooth specification V1.1 allows a maximum data transfer of 1Mbps. Our plan is to investigate whether or not channel bonding would be a cost-effective option for increasing Bluetooth data rates. Another thought is that this could provide a higher quality audio transfer, which could be appealing to consumers. 1.2. Proposal Updates The major change in our project made after our proposal was a change in hardware and software. The Mobile Choons used an Ericsson Starter Kit purchased for them by Ford. Along with this kit came a software suite supplied by Ericsson. Unfortunately for them, this software package was almost entirely inoperable and therefore the group was never able to accomplish their lofty goals. The group also had some troubles with the USB port on the Ericsson Bluetooth chips, which gave us even less confidence. At the start of our project, our intent was to inherit the boards and software from the previous group and do our best to upgrade the software. We hoped that if a complete software package was obtained, the USB issues would work themselves out and we would be able to better their performance. During this time period, the suggestion of attempting to obtain Motorola Bluetooth cards was discussed. Rich and Brett have worked for Motorola for two summers each, and they felt confident that we would be able to obtain Bluetooth hardware and software from Motorola. When Brett inquired, our request was granted. Motorola has since sent us four Bluetooth PCMCIA boards part number BTPCM100. These cards are designed to meet the Bluetooth V1.0 specification. They also sent us a software suite to use

v with these cards entitled Digianswer Bluetooth Software Suite V1.09 0808. These were the materials we used to continue our project. 1.3. Block Diagram

This was the final block diagram we used for our testing. 1.4. Specifications The following is a list of final specifications for our project: File transfer rate of 25 Kbps with a distance of less than 50 ft. line of site Full duplex file transfer Radio quality (22.050 Hz, 8 bit, mono) streaming audio with a distance of less than 50 ft. line of site. Ability to transfer files while streaming audio at radio quality Human Interference does not degrade transfer quality These specifications are quite different from the initial specifications given in our proposal. This is because the initial specifications were given with the Ericsson Starter Kit in mind. These specifications have been updated to correspond with the capabilities of the BTPCM100 Bluetooth cards designed by Motorola. The important performance variables in our project were the attainable transfer rates and the quality of the received files. Both if these variables will be discussed in detail later in this paper. 1.5. Subprojects Our project has been divided into two subprojects. The first phase, where the group devoted most of their time, was the testing of the Bluetooth cards and Digianswer software. The second phase, which played a smaller role, was the investigation of channel bonding and its applications to this topic.

vi 2. DESIGN PROCEDURE 2.1. Bluetooth Cards The Bluetooth cards we used where model number BTPCM100. Motorola donated these cards to us. The original idea, as discussed above, was to use the Ericsson Starter Kit used last semester by Mobile Choons. The starter kit may have been more desirable because of design flexibility. Those chips were freestanding units that can more realistically be used for audio applications. Unfortunately, the hardware was not operable, and we were persuaded to use Motorolas hardware. Unfortunately, Motorola has not yet developed a freestanding unit such as a development kit. The developmental boards that Motorola is constructing are not finished yet and would not be available until August at the earliest. This led us to use the PCMCIA cards, which were the only Bluetooth units the company was able to send us. Our group does not feel that we lost much in the change to the PCMCIA cards. 2.2. Bluetooth Adapters This design decision is discussed in group #45s report. 2.3. Computers This design decision is discussed in group #45s report.

vii

2.4 Software The decision to use the Digianswer Bluetooth Software Suite was directly related to the hardware we decided to use. This was the software package sent to us by Motorola to use with their cards. The version we were sent was a demo version that will eventually be released to the public. The Bluetooth Software Suite V1.09 by Digianswer is a fully qualified Bluetooth stack that supports Windows 98, Windows Me, Windows NT 4.0 Service Pack 5.0 and above, Windows 2000, and Windows XP. BTSWS contains a full-featured Bluetooth protocol and profile stack, a Bluetooth API, and a number of user applications for managing Bluetooth communication. This software is gaining popularity with many Bluetooth hardware producers. BTSWS is currently being bundled with PCMCIA and USB products manufactured by Motorola, Toshiba, IBM, DELL, and NEC [1]. In the near future, the BTSWS Evaluation Kit is being released and will allow BTSWS to be run on third party hardware. This kit will support hardware from the following vendors using a generic USB driver [1]: CSR Silicon Wave Broadcom 3Com ALPS (a CSR derivative) Taiyo Yuden (a Silicon Wave derivative)

There will also be a few specific products that will be supported such as: Compaq Multiport Bluetooth Module (an Evo N400 option) (ALPS derivative) IBM Ultraport Bluetooth Module (CSR derivative)

It is obvious that BTSWS is gaining large acceptance in many Bluetooth applications. Therefore, using this software will give us the background needed to use BTSWS in the future. 2.5 Channel Bonding Channel Bonding design decisions have been discussed in group #45s report.

viii

3. DESIGN DETAILS 3.1 Bluetooth Cards

Figure 2 Motorola Wireless BTPCM100 PCMCIA Card

Our Bluetooth cards are model number BTPCM100. These are Type II PCMCIA Cards designed according to the PCMCIA specification XX. The cards are powered by the PC at 5V DC. They have a standby power consumption of less than 1mA and an active power consumption of less than 250mA. The cards contain a +20dBm Bluetooth radio module designed according to the Bluetooth Radio Specification version 1.0. They are approved according to the CE/FCC requirements and certified according to the Bluetooth qualification for Bluetooth products. The BTPCM100 is also an OEM product. Bluetooth is a new technology that eliminates the need for cables in electronic devices such as PCs, mobile phones, speakers, etc. The Bluetooth radio contained in our cards operates in the unlicensed 2.45 GHz band, which is available to any radio system in the world. Links between these cards and other Bluetooth devices can be established almost instantly, and dont need to be within a line of site. The Bluetooth specifications also guarantee a very robust link that will not be affected by other devices operating in the same frequency band. The cards are designed for both data transfer and voice communications. The Bluetooth technology is based on short-range radio transmission with a normal range of 30 ft. The Bluetooth cards are designed to have a maximum data transfer rate of 724 Kbps. The data rate for a voice channel is designed to have a bandwidth of 64 Kbps. The cards also include some security measures. The first security mechanism is authentication. This prevents access to critical data and makes it impossible to falsify the origin of the message. The second security mechanism is encryption, which prevents eavesdropping and maintains link privacy. One final specification to note about Bluetooth wireless devices is that they support low power consumption. Our Bluetooth cards limit their output power to only what is needed. This is done by modifying its signal strength to suit smaller distances. The main goal of Bluetooth technology is to form small wireless networks known as piconets. A piconet is created when two or more Bluetooth devices form a link. The device that initiates the connection is referred to as the master, and the other Bluetooth devices are referred to

ix as slaves. The master controls all traffic flow in the piconet, and all communication between slaves must go through this device. There can be a maximum of seven active slaves for every master. In our application, we are attempting to stream hi-fidelity audio between the Bluetooth chips. This application would be very useful in an automobile setting, where speaker wires could be eliminated. It would also be beneficial for a handheld audio device, where the use of wired headsets would be eliminated. 3.2. Software

Figure 3 BTSWS Logo

3.2.1. BTSWS Description The Digianswer Bluetooth Software Suite allows us to establish a wireless link between the Motorola Bluetooth cards. This enables us to do things such as: Transfer computer files Transfer objects, for example electronic business cards (vCards) Transfer sound Access the internet by means of dial-up networking Connect to local area networks Send fax messages Establish Bluetooth ad hoc networks Connect to serial devices

As stated above, the BTSWS is a fully qualified Bluetooth Stack. The following are implemented as kernel-mode drivers in the BTSWS [1]: L2CAP SDP RFCOMM Audio Ethernet (based on the SIG current working draft)

The rest of the profiles are implemented as pluggable user mode COM objects, such as: Serial Port Profile OBEX File Transfer OBEX Object Push LAN (Data Terminal only) FAX (Data Terminal only) Dial Up Networking (Data Terminal only) Headset (both Headset and audio gateway) Synchronization is currently in development

Additionally, the software uses the Bluetooth Neighborhood application, which provides access to many features of the stack, mainly by using the drag and drop mechanism. The Bluetooth Neighborhood is very similar to the Microsoft Network Neighborhood, except it keeps track of wireless devices within range. The first basic function of this application is to carry out device discovery. This means finding all Bluetooth devices within range. The second function of the Bluetooth Neighborhood is to perform service discovery. This is when we find out which profiles the remote device supports. Finally, the Neighborhood can establish a link to the remote, allowing communication between the two devices to begin. 3.2.2. Profiles Utilized There were two major BTSWS profiles we used to test the performance of our Bluetooth cards. The first was the OBEX File Transfer profile. File transfer is a way of sharing files with others by placing them in the My Shared Files folder. Once the remote has carried our service discovery, it can access this folder and select a file for transfer. You can also send files to the remote by dragging the file icon and dropping it on the remote icon. While the file is being sent, the transfer rate is displayed at the bottom of the window. The transfer is full duplex. This was helpful to us in the testing stages of our project.

xi
Figure 4 File Transfer options

xii

The second BTSWS profile we used was the Generic Audio profile. This profile was designed for professional users only and was therefore disabled when we received the software. The code for this link is Digianswer propriety. It can basically be considered an SCO link. There were two ways we could use the audio link. The first is referred to as the Bluetooth speakerphone. This allows the two computers to be used as walkie-talkies when microphones are connected and the speakers are enabled.

Figure 5 Speaker Phone mode

The second audio mode is called the Bluetooth audio device mode. The feature allows us to send a sound file with a .wav extension on the transmitting end and record this file on the receiving end using Microsoft Sound Recorder. This application is very useful for streaming audio applications. There is also an option in this mode where the remote can enable its speaker, allowing the audio file to be listened to on the receiving end. This was useful in some human ear quality testing.

xiii

3.2.3. Bluetooth Stack The Bluetooth Stack has been discussed in detail in group #45s report. The diagram has been left for reference.

Figure 6 Bluetooth Stack

3.2.4. Bluetooth API The Bluetooth API has been discussed in group #45s report. 3.3. Bluetooth Adapters

Figure 7 Belkin Part Number F5D6000 Wireless Desktop Adaptor

The details of the Belkin Wireless Desktop adaptors have been discussed in group #45s report. The computers used didnt recognize these adapters properly, reporting driver troubles. With time becoming a factor, our group decided to acquire laptop computers instead of tinkering with these adapters any longer.

xiv

3.4 Channel Bonding The design details of channel bonding are discussed in group #45s report. The figures have been left here for reference.

Figure 8 Ethernet Channel Bonding

Figure 9 Effect of Channel Bonding on a Cluster

xv

4. DESIGN VERIFICATION 4.1. File Transfer The testing of the file transfer profile of the BTSWS is covered in group #45s paper. Figure 10 below shows a graph of transfer rates over different distances. This enabled us to gain knowledge about the capabilities of our Bluetooth cards.

Transfer Rate vs. Distance


35 30 25 20 15 10 5 0 0 25 50 75
Distance (ft) Transfer Rate (Kbps)

100

125

150

Figure 10 Transfer Rate Data for Motorola Bluetooth Cards

xvi 4.2 Audio Transfer The next set of tests done utilized the generic audio profile of the BTSWS. We first did some preliminary testing using the Bluetooth speakerphone mode. We connected a microphone to each of the laptop computers, and initialized an audio link. We were then able to use the computers as walkie-talkies. While using this feature, the voice stream was heard clearly. There was a delay of approximately 1 second introduced into the signal. There was also some echo introduced into the voice stream when the computers were placed close together. While we had an audio link established, we also successfully attempted to transfer a file. The transfer rate while the link was active was only 6 Kbps. This application would be useful in an office type setting, where it would be beneficial to transmit small files while explaining their content to a coworker. This mode is not as useful in a streaming audio application. The Bluetooth speakerphone did give us a foundation to move onto the audio device mode. The audio device mode allowed our group to play an audio file on the transmitting end and record this file on the receiving end. The audio files needed to be a .wav file in order for the profile to work. Microsoft Sound Recorder was used to record the incoming audio stream. At first, this seemed like a limitation because the sound recorder records audio in radio quality (22.050 KHz, 8 bit, mono). After our file transfer analysis, we realized that radio quality was the best quality our Bluetooth cards would be able to transmit. We also realized that the software converted any audio file to radio quality before transmission. The next step was to test the quality of streaming radio quality audio. We began with a 5 second sample of CD quality audio. We then converted this sample to radio quality audio using the Microsoft Sound Recorder. We then transmitted this sample wirelessly using our Motorola Bluetooth cards. During the first transmission, we enabled the speaker on the receiving end so we could listen to the audio sample. It was evident to the human ear that the sample had lost considerable amplification. It also appeared that some noise had been introduced into the signal. Despite these alterations, the general characteristics of the sample were maintained. Next we transmitted the sample again, this time recording the sample on the receiving side using the Microsoft Sound Recorder. Next we used MATLAB to compare some characteristics of the two signals. Figure 11 is a comparison of the two samples in the time domain. As expected, the received signal (red) has a much smaller amplitude than the transmitted sample (blue). In order to offset this discrepancy in MATLAB, we gained the received signal by 22. This gain was arbitrarily chosen by trial and error to get the closest match between the received sample and the transmitted sample.

xvii

Figure 11 Transmitted Audio Sample(blue) versus Received Audio Sample(red) in the Time Domain

Figure 12 shows the two audio samples after the gain has been added to the received sample. It is evident that the two signals are not exactly the same. The two waveforms do hold the same shape, but the transmitted waveform is more defined. The received sample seems to have lost some of its quality during transmission. The slight right shift in the received signal can be attributed to human error. The task of starting and stopping the recording was placed on us, and it was very difficult to get an exact time match between the two samples. This was our best trial.

Figure 12 Transmitted Audio Sample(blue) vs. Received Audio Sample(red) in the Time Domain after gain added

xviii The next plot we looked at in MATLAB was the frequency domain plot. Audio quality is most often discussed in terms of frequency. Figure 13 shows a comparison of the transmitted sample and the amplified received sample in the frequency domain. The frequency axis spans from 0 Hz to 22.050 KHz. It appears from this graph that the low and high frequencies of the sample were maintained in transmission. There was some noise introduced in the mid range frequencies, which was heard during the first transmission. Again, it does appear that the general characteristics of the sample were maintained.

Figure 13 Transmitted Audio Sample(blue) vs. Received Audio Sample(red) in the frequency domain

The final quality analysis plot we did on MATLAB was a spectrogram. This is a 3-D plot that looks at time versus frequency versus amplitude. This plot was suggested by a digital signal processing teaching assistant as the best way to compare the quality of the two signals graphically. Figure 14 shows the spectrograms of the two samples, with the transmitted sample of top and the received sample below it. It appears from these plots that the power in the signal is very comparable throughout the time and frequency axis. It does appear that there was some extra intensity introduced into the mid rage frequencies of the received signal. Our group attributed this to noise introduced into the signal.

xix

Figure 14 Spectrogram of Transmitted Audio Sample(top) and Received Audio Sample(bottom)

4.3 Channel Bonding The testing of Channel Bonding is discussed in group #45s report.

xx 5.COST ANALYSIS
Ford Motor Company had previously granted the Mobile Choons project a maximum budget of $10,000 for material costs. Our project is a continuation of the Mobile Choons, however; we obtained new hardware and software so we will not include previous material costs in our analysis. Previous labor costs also will not be included. The following is the cost estimation for the continuing development of this audio device:

5.1. Labor
Rory Shea and Rich Finn: Billed at an hourly rate of $30.00. Billed as one engineer with estimated 40 man-hours per week for learning, development, and testing. Billing to begin January 1, 2001 through May 1, 2001. All overtime is rated at $45/hour and is over 18 weeks. Total labor expense: $10,800.00

5.2. Materials (Shared With Group #45)


The following materials will be acquired to complete this project: Four Motorola Bluetooth cards. Cost- $10,000 (Donated by Motorola) Digianswer Bluetooth Software Suite. Cost- $200 (Donated by Motorola) Four standard Ethernet cards. Cost- $80 Two PCMCIA Adaptors. Cost- $80 Two flavors of Linux (Mandrake, SuSE) for use with Channel Bonding. Cost- $90 Two microphones. Cost- $20 Audio cable. Cost- $10

Estimated Future Material Cost: $10,400.00

Total Project Cost: $21,280.00

xxi 6.CONCLUSIONS Although our goal of transmitting hi-fidelity audio using the Bluetooth specification was not reached, our group feels we made substantial progress. Previously, the Mobile Choons were only able to transmit a voice sample. Their maximum transfer rate they attained was 8 Kbps. We reached transfer rates that exceeded 30 Kbps. This enabled us to transmit radio quality streaming audio using the Motorola Bluetooth cards. The sample did lose considerable gain during transfer and some quality was lost, but the overall characteristics of the sample were maintained. The reason that our group was not able to stream audio at a higher quality is because our hardware and software limited us. The Motorola Bluetooth cards do not appear to transfer at anything faster than 33 Kbps. This is well below the necessary CD quality sampling rate of 172 Kbps. This is such a large discrepancy that even buffering the received sample would not be a viable option. In order to listen to a 2 min song the file would have to be buffered for over 8 min. This is not practical. Another reason CD quality streaming audio could not be transmitted was the way the software was written. The Bluetooth Software Suite was not designed for streaming audio applications. Because the program is focused on voice applications, it converts all .wav files to radio quality before transmission. In order to transfer CD quality audio, this conversion must be eliminated. Also, compression and decompression of the audio would be a good addition to the software. Typically, when a .wav file is compressed to its .mp3 form, its size gets reduced by a power of ten. If this compression could be done in real time, the Bluetooth card could transfer the file in its .mp3 format. Once received, the software would then decompress the file and play it. Using this method, a transfer rate of 17.2 Kbps would be needed. This was very attainable with our current hardware. Unfortunately, the BTSWS audio profile was Digianswer propriety and we did not have access to this code. Our group does feel that there is still a future for hi-fidelity audio and Bluetooth. The new Bluetooth Specification V1.1 sites a maximum transfer rate of 1 Mbps. If hardware can be designed to reach these lofty goals, streaming CD quality audio wirelessly will become a reality. Our group learned a lot during this project. Bluetooth technology is rapidly gaining popularity, and we were able to gain a great deal of knowledge about its advantages and its limitations. We were also able to get some hands on expeience with Bluetooth hardware and software. As stated above, the BTSWS being used by a wide range of manufacturers and we now have the ability to use this software comfortably. Our team also learned more about channel bonding during this project. Channel bonding is a method for increasing data speeds that may be on the horizon, and we now have a base knowledge to work with this technology. Finally, our group was able to learn valuable people skills during the semester. We established many contacts during the semester, and more importantly gained sponsorship for this costly project.

xxii REFERENCES 1.Bluetooth Software Suite Website http://www.btsws.com. 2.BSQUARE Corporation, Bluetooth Desktop SDK, http://www.bsquare.com/products/devtools/bluetooth/desktopsdk.asp 3.Ames Laboratory, MP_Lite: Channel Bonding Fast Ethernet between PCs, http://www.scl.ameslab.gov/Projects/MP_Lite/dox_channel_bonding.html. 4.Beowulf Underground, The Beowulf Underground, March 1999 http://beowulf-underground.org/documentation.html.