RF 900 MHz STEREO WIRELESS SPEAKER SYSTEM (WSP150)

TABLE OF CONTENTS

Introduction...2 Features....2 Care and Maintaince...2 Parts...3 Instillation...4, 5, 6 Operation Notes...6 Trouble Shooting...6 Specifications....7 Warranty...7

Owners Manual

Please read before using this equipment.

INTRODUCTION

This WSP150 Wireless Speaker system uses the latest 900 MHz RF technology that enables you to enjoy stereo sound anywhere around your home - even outside on your deck or patio! Just follow the simple instructions to connect the transmitter to any audio source (CD, DSS, VCR, Stereo, Radio or TV) for full stereo sound without the need to run wires to your speakers. You may place the speakers anywhere within range (approx. 150 feet) of the transmitter to receive the stereo signal.

FEATURES

s 900 MHz RF technology. s RF technology lets you roam freely throughout your house. s Operating distance up to 150 feet. s No line-of-sight limitation. s ALC and auto ON/OFF control.

CARE AND MAINTAINCE

With proper care, your speaker system will provide you with years of enjoyment. Here are a few guidelines to follow in caring for your system: s Always use a soft cloth to clean the speakers and transmitter. If required, you may use a mild detergent and warm water to clean any dirt or dust from the component surfaces. Never use any product containing alcohol or other solvents as they may damage the surface. s Use caution when plugging the power transformers in an AC outlet to avoid the risk of electric shock. s Never expose the speakers or transmitter to rain or moisture as this may cause damage. If the speakers are used outside on a deck or patio, make sure you take them indoors in the event of a rainstorm to prevent possible damage. s Do not operate or store the system in extreme temperatures below 32oF (0oC) and above 122oF (50oC).

TRANSMITTER

FREQ. ADJUST
POWER ON / SIGNAL INDICATOR (GREEN)

AUDIO INPUT PLUG

Front SPEAKER RECEIVER

WALL MOUNT HOLE

DC INPUT 6V 800mA STEREO LED (ST.) TUNING BATTERY DOOR NORMAL/BOOST BASS POWER STAND BY LED VOLUME ON/OFF CONTROL

INSTALLATION

TRANSMITTER 1. Plug the supplied AC power adapter into an electrical outlet near your audio source. Make sure it is the one for the transmitter ("DC 19V") - the two for the speakers are marked accordingly. 2. Connect the plug end of the power adapter to the DC jack located on the back of the transmitter (see diagram). 3. Locate the audio input cord on the back of the transmitter. The 3.5 mm standard plug can be used to fit most headphone output jacks in audio equipment. If you are connecting to the audio output jacks from a TV, amplifier, etc. then plug the audio input cord into the "Y" adapter that is provided to have the standard RCA type audio plugs to connect to the audio source. If you are connecting to a TV there may be some interference to the speakers (a hum or squeal sound). If you experience this problem then use the noise filter provided. Simply plug the audio input cord into the jack of the noise filter, then plug the noise filter into the "Y" adapter for the RCA type audio plugs (see diagram). This should eliminate the interference noise. 4. Turn on the audio source. The green LED indicator light on the lower front panel will glow which indicates the unit is transmitting a signal. If it does not glow, increase the volume level of the audio source until the light glows. 5. On the back of the transmitter is the FREQUENCY ADJUSTMENT knob. This is used to adjust the RF frequency for the transmitter. For now, make sure it is set in approximately the middle of the range. This will allow you to tune the speakers to the transmitter frequency once you have the speakers ready to go. Under certain conditions, you may need to adjust this frequency to a different level in the event you encounter interference in your home from cordless phones or baby monitors. But for the initial setup installation, a mid-level setting is ideal to start with. This speaker system has automatic level control (ALC) circuitry that automatically turns the transmitter on if there is an audio signal detected and the green LED light on the front of the transmitter will glow. Once the audio source is switched off, the ALC will turn off power and stop transmitting to the speakers and the green LED will be off.

AC/DC ADAPTER GREEN LED

INSTALLATION (cont.)
AUDIO OUT STANDARD RCA CONNECTOR
TRANSMITTER (AUDIO CORD) NOISE FILTER
SPEAKER RECEIVER 1. You may use either the AC adapter or 4 - "D" size alkaline batteries (not included) to power the speaker. Make sure the "Volume On/Off Control" knob is turned to the off position. 2. If you are using the AC adapter, locate the ones marked "For Speaker" on the label and plug them into an electrical outlet located near the location for each speaker. Then insert the plug end into the DC INPUT jack located on the back of the speaker. If you are using batteries, remove the BATTERY DOOR and insert 4 - "D" size alkaline cells in each speaker making sure to insert the batteries in the correct polarity as indicated. Once the batteries are inserted correctly, replace the battery door by first inserting the bottom tabs into the back cabinet slots then closing it until it snaps in place at the top tab. Check to make sure it is closed securely before moving the speakers. You can expect the batteries to last approximately 24 hours total when the speakers are played at a mid-volume level. 3. Position the speakers about 20 feet away from the transmitter to perform this tuning setup. Turn on the speakers using the VOLUME control and set them to the desired listening level. Use the TUNING knob on each speaker to adjust the frequency until you get a clear signal from the transmitter.

20 FEET

4. If you hear static or noise and the signal is not clear, set the FREQUENCY ADJUST knob to a new setting and then try to tune the speakers using the TUNING knob on each one. If you still do not get a clear signal, make certain that other devices that use RF frequencies such as cordless phones, cell phones and baby monitors are not operating in the home when you use your speakers as they can cause interference.
5 The BASS BOOST switch can be used to enhance the sound depending on your own music preferences. To improve the bass response of the speaker, simply slide the switch to the right position. Once you have properly followed the setup procedure, you may position the speakers in any location within approximately 150 feet of the transmitter to enjoy quality stereo sound.

OPERATION NOTES

If you notice a disruption of the sound or the signal breaks up, adjust the speakers tuning control to maximize stereo reception. If you hear interference from other sources, readjust the frequency on the transmitter then re-tune the speakers the same way as described in the setup procedure. You may have to try several settings to find the one that works best in your home When transmitting or receiving over long distances, the signal from the system will become weak and the stereo indicator light will go dim. If this occurs, move the speakers to a new location closer to the transmitter to receive a stronger signal. For protection of the transmitter and to save power, the transmitter will cut off automatically in approximately one minute if there is no audio signal, or if the signal is weak. The green LED indicator light will then turn off. Once the signal is restored, the transmitter will turn on and the green LED will glow.

TROUBLE SHOOTING

NO SOUND Check that power adapters and/or batteries are connected properly and that power is on. Make sure the control knob on the speaker is ON. If using batteries, they may be too weak to power the speakers. Replace the batteries. Ensure the TV or audio component is on and that the unit is receiving an adequate audio signal. The volume control knob on the speaker is set too low. Adjust the volume if required. DISTORTED SOUND Ensure the stereo indicator light on each speaker is on. If not, adjust the tuning controls for each until the light is on. Change the position of the frequency adjust knob on the transmitter. Then readjust the tuning controls on each speaker until the indicator light is on. Speaker batteries may be too weak. Replace with fresh batteries. The speakers are too far from the transmitter to receive a strong signal. Move them closer to the transmitter. The input level of the audio signal is too low. Turn up the volume on the audio source to increase the signal level so that the green LED indicator light on the transmitter glows.

SPECIFICATIONS

Transmission Mode Carrier Frequency Operation Voltage UHF stereo 900 MHz Transmitter, 19V 200mA Speaker, 6V (8 x D size Alkaline batteries) 6V 800mA adapter (optional) 20 Hz - 15 KHz 1.5% 60dB 30 dB 50 M
Frequency Response Distortion S/N ratio Separation Operation distance WARNING:
Changes or modifications to this unit not expressly approved by the party responsible for compliance could void the users authority to operate the equipment. Operation is subject to the following two conditions: 1) This device may not cause interference, and 2) this device must accept any interference, including interference that may cause undesired operation of the device.

WARRANTY

Thomson Consumer Electronics warrants that for one year from date of purchase this product is free from defects in material and workmanship. If the item is defective within that period, return it at your expense to the dealer from whom it was purchased together with proof of purchase for replacement. This warranty excludes defects or damage due to misuse, abuse, or neglect. The foregoing represents Thomsons sole obligation under this warranty. This warranty gives you specific legal rights, and you may also have other rights which vary from state to state. For purchases in outside the United States contact your dealer for warranty information.

The ability to listen to music from a single source in multiple locations provides a useful and enjoyable enhancement for many home audio systems. However, distributing music throughout the home has proven to be logistically dicult. While home owners can extend the listening range of an audio source by purchasing a multi-room amplier, this requires the installation of additional wiring throughout the house by a professional electrician. For many consumers who do not own their homes or who cannot aord such an installation, this solution would be infeasible. The lack of a practical, aordable technology for distributing music throughout the home has resulted in the majority of consumers being conned to listening to their music in the same room as their audio source. While there has been a focus on the development of portable audio products for several years, companies have just recently begun to create products which allow consumers access to music throughout a home. This recent boom in home-wide music distribution systems has yielded a range of products, each of which address only a particular subset of consumer needs. This project developed a product that incorporated a set of features for which consumer demand is visible, but is dierent from any currently available product. These features include universal connectivity to audio sources and sinks, digital wireless transmission, many-to-many scalability, an intuitive user interface, and source control from any receiver unit. This feature set allows consumers to use their existing audio equipment and music libraries while enjoying their music at any desired location in their home. In contrast to traditional systems, this functionality is achieved without the need to install costly or inconvenient communication infrastructure in their home. Furthermore, the feature set allows multiple users to access the system simultaneously from various locations throughout a household, ensuring that the need for a truly home-wide music distribution system is met. Figure 1 shows an example of how such a system could be implemented in a house. Transmitter modules (denoted by TX) are connected to music sources and receiver modules (denoted by RX) are connected to speakers. To demonstrate the feasibility of such a feature set, we developed and implemented a proofof-concept system. This system shows how available technology can be utilized to enable a wide range of functionality. This prototype system also allowed us to conduct performance testing of the design. Data from these tests illustrated the relationship between distance and packet loss at two dierent transmission frequencies. In order to allow users to not only listen to but control audio sources remotely, an IR repeater was developed. This repeater allowed users to control audio sources using IR remote-controls supplied with audio products from any location in a home where the system is in use. The IR repeater was designed to ensure interoperability with all commonly available IR remote-controls.

alternatively choose an analog system to connect multiple audio sources but the audio quality will be degraded. Also, the maximum number of usable sources is limited to the number of available channels, which may be reduced if nearby systems are operating on the same set of frequencies. This project involved the design of a digital wireless music distribution system that addresses the shortcomings of similar consumer products that are currently available. Unlike the computerstereo link systems discussed, any standard audio source or audio sink with stereo line level connections can be connected to a transmitter or receiver in this system. In addition, the user can control the audio sources from the receivers using its standard infrared remote control. Also, unlike the analog-stereo link systems, this system is able to transmit lossless digital audio from many sources to many receivers simultaneously. Any available source can be selected from each receiver making this truly a many-to-many system. For this project, a proof-of-concept system with two transmitters and two receivers was constructed to demonstrate the feasibility and functionality of the system. Given the 54 Mbit/s theoretical throughput of the 802.11 a/g wireless links used in the proof-of-concept system, our analysis suggests that the system could support up to 38 separate streams of uncompressed audio. This report documents the design and functionality of our product, oers recommendations for future development, and provides suggestions for making it production feasible.

Chapter 2

Background
The intent of this chapter is to provide the reader with information pertinent to understanding our product design. This background chapter is divided into four major sections. The rst section of our background examines wireless home audio devices currently on the consumer market. We did this in order to understand current applications of wireless technology in home audio applications and also to scope a product with unique features. To establish our systems throughput requirements, the second section of the background explains the digital audio format used in this system. It also describes the physical connections common to many home audio devices. The third section of this chapter deals with radio frequency (RF) wireless transmission. It examines the restrictions on wireless transmission put forth by the Federal Communications Commission (FCC), which are vital to understand in order to assure our products compliance with these regulatory codes. It also describes the existing wireless protocol standards for IEEE 802.11, which were used for the implementation of this system. The nal section of this chapter examines infrared (IR) remote control standards, including wavelength and modulation frequency, since the system provides source control through infrared commands. It describes how infrared light is generated and modulated. The information in this section is provided for understanding the design of our IR repeater hardware.

Prior Art

There are many wireless audio products on the consumer market today but the vast majority fall into two general categories. The rst are analog wireless audio electronics that transmit analog audio signals using RF modulation. The second are digital audio products that use Wi-Fi or Bluetooth for wireless connectivity. The following sections will describe the general feature set of the products in these categories and cite specic product examples.
Analog Wireless Audio Electronics
There are several analog solutions for home audio distribution, of which wireless speaker systems are common. Typical systems such as the RCA WSPMHz Wireless Speakers are simply 4
speakers with an integrated analog RF receiver. A base station with an RF transmitter is connected to the audio source. These systems provide only point-to-point wireless connections and do not allow for the use of generic audio sinks nor control of the audio source from the listening location.
Figure 2.1: RF-Link AVS-5811 wireless system[1] There are more sophisticated analog systems, such as the RF-LINK AVS-5811 shown in gure 2.1, that allow for home wide audio distribution. The AVS-5811 can transmit audio and video signals on four selectable subbands in the 5.8 GHz band. It provides connectivity to generic audio and video equipment via RCA style analog inputs and outputs. Source control is provided through an IR remote extender which allows the user to use the sources remote control at the location of the receiver. The AVS-5811 is limited, however, to a maximum of four audio/video streams on the four RF subbands. The AVS-5811 also suers from signal distortion from RF interference which is a problem common to all analog wireless systems[1].
Digital Wireless Audio Products
Most of the wireless audio products emerging on the market today are digital systems. Digital wireless systems have the advantage over analog systems of immunity to distortion due to RF interference. There are also relatively new digital wireless standards such as Wi-Fi (IEEE 802.11) and Bluetooth that are gaining popularity and making digital wireless systems cheaper to produce and easier to develop. Digital wireless solutions are also well suited for applications where the data stream is already digitized, such as when interfacing with an MP3 music library.
Figure 2.2: Apple AirPort Express with AirTunes[2] 5
Recently, a number of companies have released digital wireless audio products for accessing a digital music library on a computer from the home entertainment center. Some of these products are the SMC EZ-Stream Wireless Audio Adapter and the Apple Airport Express (gure 2.2)[3][4]. Most of these systems only oer a point-to-point connection between a speaker system and a PC with music library software and a Wi-Fi card. Inherently, these systems are limited in that they do not support connection to generic audio sources and require an existing 802.11 wireless network.

Most common audio sources and sinks have analog audio outputs and inputs respectively. Normally, the analog connectors on these devices are stereo RCA jacks which allow connectivity of line level audio signals. Line level audio is a low power signal that is designed for high impedance loads. This signal is intended to transfer the audio from one device or circuit to another. Additionally some devices, such as portable CD and MP3 players, provide an 1 headphone output. The signal 8 from this connection, unlike line level audio, is intended to deliver power to low impedance loads. The system must be able to accept both types of signals and to produce line level signals to ensure its compatibility with generic sources and sinks. To preserve audio quality, our product will handle audio signals digitally. To obtain digital audio from a generic analog source, the analog audio signal must be sampled and converted to a digital representation. An analog to digital converter (ADC), like the one shown in gure 2.5, performs this operation. The sampling frequency and resolution of the ADC, which can be varied as required for a particular application, determine the bitrate of the digital audio stream. In this application, audio is captured at CD-quality. This implies a sampling rate of 44.1 KHz and a resolution of 16 bits. Two such channels of this digitized audio, comprising a stereo stream,
correspond to a total data rate of 2(44100 samples bits bits 16 ) = 1411200 s sample s
In other words, the digital transfer of each stereo audio stream requires 1.41 Mbps (Megabits per second) of throughput over the transmission medium.

Analog Audio

Right Left

Digital Bitstream

0010010101101110.
Sampling Frquency Resolution
Figure 2.5: Analog to digital conversion

Wireless Regulations

In order to select an appropriate radio frequency for wireless transmission, it was crucial to understand the government regulations that apply to RF radiating devices. Since this system was developed in the United States and primarily for use in the United States, only the US regulations were considered for this project. The Federal Communications Commission (FCC) regulates all RF transmissions in the United States. Many bands of the frequency spectrum require a special license from the FCC in order to transmit above a certain power level. The FCC also denes parts of the spectrum that can be used without a license provided the device does not exceed the specied eld strength and any additional provisions for the band or application are met. The requirements for unlicensed transmissions are dened in the FCC Code of Federal Regulations Title 45, Part 15[6].
Intentional Radiator Field Strength Limits
Subpart C of the Part 15 regulations denes the eld strength limits for intentional radiating devices such as a wireless transmitter. Figure ?? shows the maximum eld strength (in V /m) versus frequency for intentional radiators as dened by these regulations[6]. Note that the restricted bands in which no transmissions are allowed are not shown. The highest eld strengths below 10 GHz are around 900 MHz, 2.4 GHz, and 5.8 GHz and are known as the Industrial, Scientic, and Medical (ISM) bands. The ISM bands are the only frequency ranges available with enough bandwidth and permitted eld strength for the high throughput wireless connection required for this project.

of packets. UDP datagrams can be broadcast to a local subnet so that all devices on the subnet will hear the message. However, in many cases only certain devices on a local network are interested in receiving the data packets. Multicast goes a step further by selectively sending datagrams to all members of a multicast group. Devices on a local network can join the multicast group by listening to a certain multicast address. In this way, packets only need to be sent once to be received by all members of the multicast group. This method is far more ecient than multiple TCP connections but at the cost of guaranteed packet delivery[12]. A number of multicast protocols have been designed to deal with UDPs unreliable nature. One popular protocol for delivering audio and video is the Real-time Transport Protocol (RTP). This protocol provides sequence numbering, time stamping, delivery monitoring, and payload-type identication of UDP packets. The protocols main advantage is that it provides consistent order of packet delivery while still supporting multicast streaming for real-time applications. However, RTP does not retransmit packets that are lost during transmission[13].
Infrared Remote Control Basics
A simple way of providing source control for the wireless music distribution system was to make use of the infrared (IR) remote controls common to most home audio electronic equipment. These remote controls use IR light to transmit a message signal from the remote to the audio source. An infrared light emitting diode is often used to produce the IR signal. A digital control message is encoded by varying the width of high and low pulses. The electronic equipment receives the message using an infrared phototransistor and executes whatever command has been hard-coded to correspond with a given combination of ones and zeros. While the duration of the baseband binary pulses is generally around 0.5 ms, the information is modulated on a high frequency carrier wave in order to avoid interference from ambient IR light. The frequency of this carrier wave varies from about 38 KHz to 50 KHz for most home electronic equipment. Figure 2.8 shows the carrier wave modulated in an on-o keyed manner by the binary information. The incoming signal is decoded by the audio equipment through a low pass lter, which removes the carrier wave while retaining the baseband message.
1 0.8 0.6 0.4 0.Baseband Digital Signal Modulated Carrier

0.5 time

0.9 x 10
Figure 2.8: Infrared signal with carrier wave

Chapter 3

Methods and Solutions
This chapter describes the framework of our product and the design decisions we made that allowed us to meet these requirements. This chapter begins with a list of technical specications that served as a primary guide in the research and selection of the hardware platform for the two-by-two system. Additionally, this chapter discusses the hardware selected for our infrared extender and our user interface. The software section contains an overview of our operating system choice and an explanation of the applications that were created for the transmitter and receiver units. Procedures and setup parameters for our system performance tests are given in the nal section of this chapter.

us to use high-quality IR receivers, much like those found in most audio equipment that receives IR signals. These IR receivers can receive the remote signal over a large range of distance, even when the remote control is not pointed directly at the IR receiver. Our IR repeater hardware is very compact, relatively inexpensive (approximately $25 per unit), and easily ts within the enclosure that was chosen for our other hardware.
Figure 3.5: IR repeater transmitter and receiver circuits The nal step in the design of our IR repeater involved the creation of a means to transmit the IR signal from the RF receiver back into the audio source. While an IR light emitting diode (LED) is capable of performing this task, it needs to be placed in direct line of sight with the audio source. For this purpose, we built a wire that connects to our product and has an IR LED at the end of it. With this wire (seen in gure 3.6), we could position the IR LED very close to the audio source to ensure that the IR light reaches the source. For connection between the wire and our product we chose to use RCA connectors. We used these because they were capable of passing the type of signal we used through a shielded conductor and also because our product already had the space for an RCA connector. Additionally, these RCA connectors were available in bulk-head style, which allowed us to mount them onto our enclosures and provide simple, eective strain relief from the connections to our soldered circuit boards. The use of an RCA jack, as opposed to a permanent wire, has two major benets. First, if for some reason the wire gets pulled on, it will simply disconnect from the enclosure without damaging the wire or the circuitry. Also if the audio source does not have an IR remote, the IR LED wire can be removed completely.
Figure 3.6: IR LED with RCA connector

Enclosure

Since the motherboard used was a Mini-ITX form-factor, we were able to select an enclosure with standard mounting points for Mini-ITX motherboards. The enclosure selected was the Casetronic ITX-2699R. This enclosure had mounting points and brackets to attach the Mini-ITX motherboard, the hard drive, and wireless network adapter. The enclosure also included an external 120VAC to 12VDC power supply and an internal DC to DC converter to supply the necessary voltages to the internal components including the motherboard, the IR repeater, and the LCD display.
Figure 3.7: Inside enclosure view The enclosure required modication to accommodate both the LCD module and the IR components (emitter and detector) on the front panel. The front part of the case was removed and cut at the Washburn machine shop at WPI. A large rectangular hole and four mounting screw holes were 19

Figure 3.11: Audio streaming over the network all clients and servers before connecting to the network. When a client joins the network, it sends a request for status information to this address. All servers on the network listen to this address and respond to the client using a TCP/IP unicast connection. The response includes the servers logical name, the servers IP address, and the servers stream multicast address. After the query and response operation has completed, the client has a complete list of all available servers on the network. An illustration of this operation is presented in gure 3.12.
Figure 3.12: Server Discovery initiated by clients query
Control and Status Communications Servers and clients that are connected need to be able to send information to one another. For instance, a client sends a signal to a server whenever it connects to or disconnects from that servers stream address so that the server can keep a count of how many clients are connected. Since these messages are critical, they are sent via a TCP/IP unicast connection, as shown in gure 3.13. Because TCP/IP unicast employs packet conrmation and retransmission, the messages are sure to reach their destinations. While these messages require relatively more network bandwidth because of the overhead associated with this handshaking, the messages are small and relatively infrequent so the additional load on the channel is acceptable.

Server A Client A

Figure 3.13: Control and status communications between clients and servers

Software Implementation

We will now describe the programs we have written to perform each of these functions. We elected to develop our software as separate programs that run concurrently to allow for parallel execution of independent tasks. The majority of our functions were implemented with server-client pairs of applications with the exception of the user interface which runs only on the client machine. The server applications and their operation are shown in the block diagram below, gure 3.14. Similarly, the client applications are shown in gure 3.15. The solid arrows indicate a process initiating another process (for example the Control and Status Handler initiating the Query Handler). The dotted arrows indicate inter-process communications, either by means of a data pipe or software interrupt (a.k.a. signal) and the dashed arrows indicate network communications between client and server machines. Streamer and Player Applications The Streamer and Player applications perform the audio transport function of the system. On the server side, the Streamer program, streamer, reads audio samples from the sound card. In Linux, this is achieved by reading from the /dev/dsp device. After 1024 bytes (or 256 stereo 16 bit samples) have been acquired, they are sent in a multicast packet to the servers designated stream address. This packet size was chosen because reading from the sound card is most ecient when

c c Query Handler Control & Status Handler

Streamer

Figure 3.14: Server Applications

c c Playback Controller

Player

Lookup Manager

UI Console
Figure 3.15: Client Applications
it is done in block sizes that are powers of 2. Since the MTU (Maximum Transmission Unit) for a datagram is 1500 bytes, a block size of 1024 ensures a minimal amount of average packet overhead. The operation is looped indenitely until the streamer process is killed. The complimentary client application is the Player program, player. When player is initiated, it is given the desired servers stream address as a command line parameter. It receives packets from this address and writes them to the /dev/dsp device, which causes the audio to be sent to the line out of the sound card. Like streamer, player will continuously loop until it is killed. Lookup Manager and Query Handler Applications The server discovery operation is implemented with a pair of programs, the Lookup Manager on the client side and the Query Handler on the server side. When the Lookup Manager application lookup is initiated, it makes a connection to the server status query multicast address. It sends a packet containing its own IP address and port for TCP/IP communications to this address. Since the UDP multicast packet does have guaranteed delivery, lookup sends this same information ve times. The intent of this redundancy is to increase the probability that the message is received by the servers. After lookup has sent its information to the Server Status Query address, it listens for replies from servers on the port specied in the sent query message. The Query Handler application, query runs constantly on the server machines. Query listens to the Server Status Query multicast address, waiting for client queries. When it receives a packet, it 25
parses the message into the IP address and port and saves these values in local variables. It then forks o a child process to handle the reply so that the parent can listen for more queries. Each child process establishes a TCP/IP connection to the IP address and on the port specied in the message. To that IP and port, query sends the server machines information, including the units name, its IP address and a port for TCP/IP communications, and the servers multicast stream address and port to listen on. Since this message is sent via TCP/IP, it has guaranteed delivery and therefore does not need to be sent redundantly. One feature of the Query Handler is that for a given amount of time after a rst query, it only responds to unique IP addresses. This prevents unnecessary redundant replies to the same client; the client will query ve times but will only be responded to once. After a short period of time, query clears the list of old IP addresses so that clients can perform server lookup operations again at a later time without being ignored. As stated before, the Lookup Manager waits for server replies after it has sent the client machines information. Similar to the query, lookup forks a new child process to handle replies every time a new server responds. This way, if server A and server B both respond to a clients query at approximately the same time, the client will not miss the second response while it is processing the rst. Each child process establishes a TCP connection with the responding server and receives the servers information. It then parses this message, stores the servers information in a le, servlist.txt, and quits. When ample time has elapsed following the initial query, lookup stops listening for server replies and quits. By this time, the servlist.txt le contains a complete list of all servers on the network. Control and Status Handler and Playback Controller Applications The Control and Status Handler, control, and Playback Controller, playback, applications are the main threads from which all others spawn on the server and client machines respectively. When the machine is started up, one of these two programs is executed and the machine goes into either server mode or client mode. When the Control and Status Handler program is run, it spawns a Query Handler process immediately. Query runs in the background continuously while the machine is in server mode. Control also handles TCP/IP communications with clients. It will bind to a designated port and wait to accept incoming messages from clients. Like many of our other programs, when a client connects, control spawns a child process to receive and handle the message while the parent waits for more connections. A client will either send either a connect or a disconnect message to a server which will react by incrementing or decrementing a counter variable that keeps track of the number of listening clients. If that counter becomes greater than zero, control will initiate a streamer which will start streaming audio to that servers designated stream address. If the counter becomes zero, the streamer process is killed, preserving network bandwidth. The Playback Controller initiates the user interface program on startup using a popen() command. This opens a one-way pipe between the child processs standard output (stdout) and an input le descriptor in the parent. The UI program sends play and stop commands to the Playback Controller using this pipe. A play command comes through as an integer corresponding to a server in the servlist.txt le. The playback controller opens this le and extracts the necessary information for the requested server. It then sends a connect command to the server via TCP/IP, and initiates a player with the servers corresponding multicast stream address. When playback receives a stop command, it sends a disconnect command to the server and kills the player program. If the client is already playing a stream from one server and another play command appears on 26

the pipe, playback performs the stop operation, followed by the play operation so that there are never multiple players active at any time.

User Interface Design

The UI was designed and implemented as a series of states. Each state consisted of a message to be displayed on the LCD and a dened set of responses to button presses. These states can be seen in table 3.1. States 10 through 60 represent the Player Mode (client operation) and state 500 represents the Source Mode (server operation). The button press responses were designed to be as consistent as possible between states. For example, the LEFT button switches between Player and Source Modes, the RIGHT button searches for additional music sources in many of the Player states, and the CHECK button plays the selected source in several modes. This was intended to increase usability as it reduces the number of functions each button has. The text displayed was written to be succinct so that it would t into the 32 character spaces available on the display. This necessitated careful consideration to choose the most important information to display in any given state.
System Performance Testing
After the hardware and software was designed and integrated, it was necessary to test the system performance to ensure it met the technical specications and to nd ways of improving the nal product. Performance tests were designed to test the audio streaming capabilities of the system. The rst test determined the throughput capacity of each system. The throughput determines the maximum rate at which each device can transfer information. The second test measures how the packet loss increases with distance. This is directly related to the audio quality over distance. The last test measured the eect of interference caused by simultaneous audio streams.

Throughput Testing

To test the throughput of the wireless link, a program was written to multicast UDP packets at various rates. The test program multicasts the packets with the exact same method as the streamer application in the software design. The test program allows the tester to specify how many packets are sent at once (burst size), the delay between packet bursts, and the packet size. Another test program listens on the multicast address and port and records each of the packets it receives to a le. Each packet is numbered by the transmitting test program so the receiving program can scan its received packets le to locate missing packets. It then records the total number of packets lost and calculates the packet loss rate. The transmitting and receiving test programs are called streamtest and streamrecv respectively. These programs were used to test various throughput rates by adjusting the burst size, packet size, and burst delay parameters. The approximate throughput in bytes per sec can be calculated simply by multiplying the burst size by the packet size and dividing by the burst delay. Initial testing on laptop computers showed that independent parameters had little eect beyond the total throughput as long as the packet size was less than the Maximum Transmission Unit (MTU) 27

1 Packet size = 1000B 0.9 0.8 0.7 Packet loss (%) 0.6 0.5 0.4 0.3 0.2 0.Distance (m) 40 50
Figure 4.2: 802.11g Packet loss vs. distance Table 4.1: Self-interference test results Packet Loss 802.11a Packet Loss 802.11g 0% 0.13% 0.22% 0.05% 0.15% 0.25%
Test A (1 to 1) Test B (Unidirectional) Test C (Bidirectional)
Self-Interference Test Results
In order to quantify how the system scaled with multiple streams, tests were performed using the procedure described in 3.4.3. In the one to one case, a single audio stream was transmitted at 30 m. The unidirectional test sent two streams simultaneously from two servers to two clients at a distance of 30 m. The bidirectional test reversed the direction of one audio stream so each listening client was below a transmitting server. The results of these tests are presented in table 4.1. The table shows how packet loss increased when subject to more interference from simultaneous streams. The system scales reasonably well with two simultaneous streams. As expected, the bidirectional case introduced the most interference because each client was immediately below a streaming server while attempting to listen to another audio stream being sent 30 m away. However, due to the collision detection management capabilities of 802.11 even in this case the packet loss was well less than 1%. Unfortunately, it was not possible to test with more streams because only a two-by-two system was implemented.

Results Summary

The testing performed demonstrated the single device throughput limit, the wireless range, and the scalability with simultaneous streams. 802.11g had about twice the throughput capability as 802.11a for a single device. This could become important if a larger data stream is used such as video. The exact cause of the throughput limit could not be determined, however, and could simply be the result of a non-optimized driver that is still under development. 802.11a demonstrated better scaling with distance and achieved packet loss free streaming at 45 meters. 802.11g also performed well with packet loss rates under 1% up to 45 meters but there was a noticeable increase with distance. Both wireless protocols performed similarly with self-interference caused by simultaneous streams. The tests demonstrated that the two-by-two system performs well under worst case conditions for self-interference. Further testing remains to characterize the system with more devices and under external interference.

Summary

Following these recommendations could yield a music distribution system comparable in size and cost to currently available products. A packet loss handling method could improve the systems immunity to interference, allowing it to operate in higher noise environments and with multiple concurrent streams. Scalability testing would provide information on how the system behaves as the number of simultaneous streams increases. While these recommendations are provided as methods of improving our music distribution system, solutions to these problems could have a wide variety of applications. They could be useful in any system which requires streaming of real-time data between multiple nodes in a networked setting.

Appendix A

Project Description
Available at http://spinlab.wpi.edu/Projects/opportunities/ Many-to-Many Digital Music Distribution System Project Sponsor: Bose, Inc. Terms: A05-C06 Project description: In this project, students will develop a many-to-many digital wireless music distribution system. In general, such a system would have M audio sources (e.g. a CD player, a DVD player, etc.) and N audio sinks (typically ampliers and speakers but also wireless headphones, etc). No cables connect the sources to the sinks. The students will develop a transmitter module that uniquely identies each audio source, allows for control of the audio source, allows for querying of the state of the audio source, and allows for digital audio streaming from the source. The students will also develop a receiver module that allows the user to select an audio source, request the state of the audio source, control the state of the audio source, request audio from a desired source, decode the audio, and play the audio. A key component of the project is that multiple sources should be able to stream audio simultaneously to multiple sinks. The general benet would be that no cables would be required and you could listen to any audio source with any audio sink. The student team will be required to research prior work in this area as well as build and demonstrate a 2 source by 2 sink proof of concept. The student team will evaluate and select existing digital wireless technologies to realize the wireless links.

Appendix B

Product Requirements
The work done on this project is based on the project description, shown in Appendix A. This description served as customer requirements, and was the basis for creating a list of minimum product requirements. Together, these minimum requirements are unmet by any product currently in the consumer market. Wireless digital communication link This requirement is fundamental to the project, with wireless and digital being two basic customer requirements Many-to-many scalability This means that while it is only necessary to physically build two transmitters and two receivers, the software designed and the hardware platforms selected must be capable of incorporating more wireless components into the system. Meet Federal Communications Commission (FCC) standards for continuous wireless transmission The FCC is the governing body in charge of all wireless transmission, and it is necessary for our product to abide by their regulations. Failure to adhere to these rules can result in serious nes, and would invalidate the project as a marketable product. Ensure compatibility with home audio sources and sinks One of the major shortcomings of current wireless audio products is the lack of compatibility with many common home audio sources (such as CD-players) and also home audio sinks (such as speakers and stereos). This product will address that shortcoming by having a common audio input format and audio output format to enable connection to almost all consumer audio equipment. Provide source control from receiver For usability purposes, it is very important to have some form of source control from the receiver module. A consumer listening to wirelessly transmitted music in one room will not want to have to go into the room with the audio source just to pause, play, fast-forward, etc. This product will therefore provide added convenience and usability by allowing the user to perform at least rudimentary functions from any room with a receiver in it. Provide visual indicators for user This requirement is again based on increasing simplicity and usability for the consumer. We 41

plan to have some form of user interface on the receiver module to show the existence of a wireless link between a transmitter and receiver, and also to indicate the reception of any commands that are being sent back to the source. Provide home-wide transmission of audio signal This requirement necessitates the selection of some wireless transmission technique by which receivers can be set a reasonable distance apart, with walls between the transmitter and receivers.

Appendix C

Bill of Materials
Presented here are the materials costs for the two-by-2two proof of concept system developed for this project, comprising 4 total machines.
Part No. VIA ML5000 Casetronic Black ITX-2699R Linksys WMP55AG Crystalfontz 633 Linx RXM-433-LC-S Linx TXM-433-LC Linx ANT-433-SP CUI RCJ-031 CUI RCP-011 LED-PhotoTX1 276-640 Vendor directron.com directron.com newegg.com crystalfontz.com digikey.com digikey.com digikey.com digikey.com digikey.com digikey.com Radio Shack WPI ECE Shop WPI ECE Shop WPI ECE Shop WPI ECE Shop WPI ECE Shop WPI ECE Shop WPI ECE Shop WPI ECE Shop Description Mini-ITX x86 SBC Mini-ITX Computer Case PCI Wireless A+G Network Adapter RS-232 LCD unit 433MHz Wireless Receiver Module 433MHz Wireless Transmitter Module 433MHz SPLATCH Planar Antenna RCA jack, panel mount, black RCA plug, black Infrared LED Infrared Receiver Modules 100 5% resistor 200 5% resistor 430 5% resistor 1K 5% resistor 10K 5% resistor 150K 5% resistor 100pF capacitor Miscellaneous wire and heat shrink tubing Price $171.99 $62.99 $79.99 $55.00 $13.76 $6.90 $2.08 $0.71 $0.88 $0.50 $3.69 $0.10 $0.10 $0.10 $0.10 $0.10 $0.10 $0.40 Qty Total: Cost $687.96 $251.96 $319.96 $220.00 $27.52 $13.80 $4.16 $1.42 $1.76 $1.00 $7.38 $0.10 $0.10 $0.10 $0.10 $0.20 $0.10 $0.40 $1.00 $1540.12

Appendix D

Software Revisions and Driver Issues
This appendix lists the software and driver revisions used in this project. It also describes some of the issues encountered when using dierent third-party drivers and software.
Software and Driver Version List
Debian 3.1 Linux Kernel: 2.6.8-2-386 Madwi Atheros Chipset Driver: r1452 Advanced Linux Sound Architecture (ALSA): 1.0.8 Wireless Tools for Linux: 27-2 TCPDump: 3.8.3
Other Software Evaluated During This Project (not used in nal implementation)
Linux Kernel 2.4 Open Sound System (OSS) VideoLAN Client (VLC) Ndiswrapper 1.7 Linuxant Driverloader Intel PRO/Wireless 2100 Driver for Linux

Software and Driver Issues
Several Linux kernel revisions were evaluated during this project. Recent stable revisions of the 2.6 Linux kernel proved to work the best for this projects application due to integrated ALSA support and compatibility with the latest wi drivers. Both ALSA and OSS were tested for audio support. Problems were encountered when using OSS for audio capture and playback. Moving to a Linux 2.6 kernel with integrated ALSA and installing the latest ALSA development packages (using apt-get) resolved these audio issues. The program alsamixer was used to adjust volume levels and capture from line-in. Numerous wireless driver issues were encountered over the course of this project due to the continual development of wireless drivers on the Linux platform. Both native Linux driver and nonnative Windows driver wrappers were tested for the wireless cards used during the project. Early laptop development used the Intel PRO/Wireless 2100 card. Both the native driver for Linux and the Windows driver using the Linuxant Driverloader were tested. After encountering issues with both drivers, they were eventually both able to work on an ad-hoc wi network with multicasting. For the Linksys WMP45AG card based on the Atheros chipset used in the nal system, both native and non-native drivers were evaluated. The Madwi native Linux driver initially failed to work in ad-hoc mode. The Ndiswrapper with the latest Linksys WMP45AG driver for Windows was tested and was able to create an ad-hoc network. However, this driver had issues with multicast streams and was generally unreliable. Finally, a later revision of the Madwi native Linux driver was tested and was able to reliably connect to an ad-hoc network. Multicast transmission rates, however, were limited until the proper conguration was determined (see the conguration scripts madwi-netsetup-a.sh and madwi-netsetup-g.sh in the systems root directory). As the Madwi driver is in a continual state of development, new driver revisions should be evaluated as they are released.

Appendix E

Setup Procedure
This appendix details the procedure for setting up the two-by-two proof of concept system implemented in this project. Step 1: Boot the machine with the 2.6 Linux kernel. Step 2: Login as root with password m2mBrovn13. Step 3: From the root directory ( /), run the shell script to setup the wireless network. For an 802.11a network run: sh madwifi-netsetup-a.sh. For an 802.11g network run: sh madwifi-netsetup-g.sh. Step 4: Navigate to the subversion repository (e.g. /home/m2m/project/orpheus/trunk/). Step 5: Use the make le to build the executables. (See the Makele for options). Step 6: Run the Control and Status Handler Application by invoking./control at the command line. You should now be able to control the system from the front panel UI. Step 7: Run alsamixer to adjust volume levels and to capture the audio source at line-in (press F4). Perform these steps on each of the machines.