University of Central Florida
Bluetooth Wireless MP3 Player
Computer Engineering Program
School of Electrical Engineering & Computer Science
University of Central Florida
Orlando, FL 32816-2450
Team Members:
Project Mentor:
Jesse Gusse
Gusseology@cs.com
Sylvester Harding
Sylharding@hotmail.com
Jim Killingsworth
JKillingsworth@cfl.rr.com
Charles Osborne
utwebgeek@earthlink.net
Janusz Zalewski, Ph.D.
jza@ece.engr.ucf.edu
-1-
Abstract
The Wireless MP3 Player allows the user to access, via Bluetooth, MP3 files located on
their PC's, and listen to them with a set of headphones from anywhere in the house. The
user interface is on a Palm computer (client) which shows a listing of the MP3's that
currently reside on the remote PC (server), as well as commands to control the song (or
other audio) selection, play, pause, etc.
Communication, via Bluetooth, between headphones and Palm on client side, and MP3's
on the server side, is controlled by a microcontroller. The user selects an MP3 via Palm,
the command is sent via the microcontroller, through Bluetooth, to the server, which then
streams this selected MP3 back, via Bluetooth, and the microcontroller directs it to the
user's handheld device, which is then played through their headphones.
The report describes…
-2-
1. System Overview
MP3 players have made an impact on the market, yet still lack in sufficient data
storage. Home PC's have been able to handle mass data, but unless a user is near the PC
audio speakers, they can't take advantage of their mass amount of MP3's. The objective
of this project is to address both problems and develop an MP3 player with wireless
access to PC storage.
The system to accomplish this task is an MP3 Wireless Player. It is a Personal Area
Network for home use (Fig. 1). In essence, the system will allow a user to access and
listen to his or her MP3's located on their PC's from anywhere in their house with a set of
headphones. The user interface is an LCD display (client) which will present a real-time
listing of the MP3's that currently reside on their remote PC (server), as well as
commands for the user to control the song (or other audio) selection, play, pause,
etc. First, the user selects an MP3; the server then will stream this selected MP3 to the
user's handheld device, which will then be played through their headphones.
Fig. 1 MP3 Wireless Player
-3-
This way an individual can listen to any of their MP3's anywhere in or around their
house or place of business. The market demand for this is outweighed only by the further
potential applications. It can then be extended to include any sort of audio output, such
as an answering machine, etc. With permission, users can possibly one day access an
MP3 server anywhere that is within 100 feet of them.
This project includes both software and hardware design. The goal is to make a
reproducible, affordable, and efficient product that meets a market demand.
1.1 Requirement Specification
1.1.1 General Overview
The system has two major components, the Client and the Server (Fig. 2). The Client has
multiple inputs and multiple outputs. The Client's inputs are the Bluetooth signal from
the Server and operator commands from an external interface. The Bluetooth signal is
what data is streamed to; for this system it is MP3 and items list data (songs, other audio
files, etc.). Operator commands are such as PLAY, PAUSE, STOP, etc.
Fig.2 MP3 Wireless Player System Architecture
-4-
The Client's outputs include audio signal, local screen output, as well as service requests
to the Server. The audio signal is for the user to listen to the MP3's he or she
chooses. The local screen output is composed of text messages addressed to the
operator. The service requests go to the Server from the Client and include which song to
choose.
The Server has multiple inputs and outputs as well. Its inputs include the Bluetooth
signal which carries commands and service requests from the Client, which are the same
as Client's outputs, but also regular file access to MP3 data. The Server's outputs include
MP3 and song list data and are identical to respective inputs of the Client.
1.1.2 Functional Requirements
1.1.2.1
The Client shall accept from the operator the following commands to the
Server: SELECT, PLAY, PAUSE, SKIP, and CANCEL. Further commands
may be added later.
1.1.2.2
All commands accepted by the Client from the operator shall be transmitted to
the Server via Bluetooth signal.
1.1.2.3
The Server shall be able to handle commands from multiple Clients
simultaneously.
1.1.2.4
The Server shall react to the SELECT command by providing the client with a
list of audio files available for transfer.
1.1.2.5
The Server shall react to the PLAY command by sending the requested data to
the Client. This data will be decoded by a DSP since it is in MP3
format. There will be a buffer so that the MP3 is consistent and not cutting in
and out.
1.1.2.6
The Server shall react to the first PAUSE command by stopping the stream of
data, yet remaining at the same location within the MP3..
-5-
1.1.2.7
The Server shall react to the second PAUSE command by starting at the
memory location at which the first PAUSE command stopped it.
1.1.2.8
The Server shall react to the SKIP command by ending the current MP3 it is
streaming and skipping to the next or previous file in the file directory, and
then stream this MP3.
1.1.2.9
The Server shall react to the CANCEL command by ending execution of any
currently executing command and placing itself in an initial state.
1.1.2.10
In case the Server is unable to react to the Client's command correctly, it
should return an error message as follows: "Cannot process request, please
choose again".
1.1.2.11
The Client shall accept the MP3 data sent from the Server, in the following
forms:
1.1.2.12

File list as plain text, and

MP3 encoded data.
The client shall generate the audio signal in response to the MP3 data received
and deliver it to an output such as a pair of headphones.
1.1.3 Performance Requirements
1.1.3.1
The Client shall primarily be battery powered since it is the mobile unit of the
overall system.
1.1.3.2
It will be designed to accept SELECT, PLAY, PAUSE, SKIP, and CANCEL.
from the operator and process them accordingly through the server.
1.1.3.3
MP3 data will be streamed from host computer (server) and send via
Bluetooth to the Client.
-6-
1.1.3.4
To maintain a “near CD quality” sound, the device should be capable of
receiving and playing MP3 file of 128 kbit/s bit rate; thus MP3 data transfer
will be about 160 kbits/s which is well in the range of Bluetooth capabilities.
1.1.3.5
The required tranmission range of the device will be approximately 100 feet,
since it is a home application.
1.1.3.6
The mobile unit will also contain a memory buffer which will allow data to be
stored for continuous listening.
1.1.3.7
The system should be light in weight and very cheap to produce, especially
since the primary consumer is a home user.
1.2 Design Methodologies
The development methodology used for this project is called the Waterfall Model. It has
been selected because it is simple and well understood by the project team. According to
this methodology, the project was accomplished in overlapping steps, consisting of one to
two cycles of requirement specification development, hardware design, software design,
test plan development, hardware and software implementation, testing, independent
V&V, documentation and product delivery (fig. 3).
-7-
Fig. 3 Project Activities According to Waterfall Model
To achieve maximum productivity and efficiency, these various design steps were
developed and implemented simultaneously by each team member independently and
then implemented as a single unit upon completion. The overall design was made such
that the device would be easily reproducible and open-ended for potential upgrades such
as outputting audio signal to different audio devices, allow the mobile unit to connect to
any MP3 server, when given proper permission, and so on.
-8-
1.3 Innovation
Many people who start collecting MP3 files find that they want to listen to them in all
kinds of places. In response to this demand came the birth of portable MP3 players.
These players have one key limitation though; the amount of MP3 music accessible to the
listener is limited to the device’s physical memory or storage capabilities. Our wireless
MP3 player eliminates this vital limitation by providing the home user unlimited realtime access to his/her entire MP3 library collection. This device will be very unique,
especially since wireless MP3 players do not exist. When further developed, the device
could become a key element in a user’s personal area network. It could be developed to
interface with all audio and data dependent devices such that the user could be able to
answer phone calls from the home telephone line, listen to answering machine, see the
phone number of incoming calls, receive email alerts and so on. At the recent Wireless
2002 show in Orlando, none of the top companies demonstrated a Bluetooth enabled
MP3 player.
-9-
2. Implementation and Engineering Considerations
2.1 Design Description
2.1.1 System Architecture
The system has two major components, the Client and the Server, both of which use a
Bluetooth module for data transmission between each other, within a range of 100 feet
(fig. 3).
RS232
M100
Palm
Computer
Windows Based
Personal Computer
USB
RS232
I2 C Bus
MP3 Data
ATmega128
Microcontroller
STA013
MP3 Decoder
Bluetooth Radio Link
Bluetooth
Module
PCM
Bluetooth
Module
CS4334
D/A Converter
Server
Analog Audio
Headphones
Client
Fig. 4 Block Diagram Showing System Components
The Client's inputs ports include a Bluetooth signal from the Server, and operator
commands from an external interface. The Bluetooth signal is what data is streamed to;
- 10 -
for this system it will be MP3 and items list data (songs, other audio files, etc.).
Operators commands are commands such as SELECT, PLAY, PAUSE, STOP, SKIP and
CANCEL. The Client's outputs include an audio signal to a pair of head sets, local
screen output to a PDA device, as well as service requests to the Server. The audio signal
is for the user to listen to the MP3's he or she chooses. The local screen output is
composed of text messages addressed to the operator. The service requests go to the
Server from the Client and include which song to choose and so on. The client will also
be composed of a buffer to ensure synchronous play of music.
The Server has multiple inputs and outputs as well. Its inputs include the Bluetooth
signal which carries commands and service requests from the Client, which are the same
as Client's outputs, but also regular file access to MP3 data. The PLAY command will be
processed by streaming the required MP3 file to the client. The Server shall react to the
SELECT command by providing the client with a list of audio files available for transfer.
The PAUSE command will be processed by stopping the stream of data, while remaining
at the same location within the MP3 file. The SKIP command will be executed by
reverting to the previous, or advancing to the next MP3 file on the play-list. CANCEL
commands will involve termination of executing command and a return to initial state.
When as case arises in which the Server is unable to properly execute a command from
the client, it should return an error message as follows: "Cannot process request, please
choose again". It is important to note that the user will already have a personal computer
which he/she will use a server, after installation of the application software. The Server's
outputs include MP3 and song list data and are identical to respective inputs of the Client.
The Server shall be able to handle commands from multiple Clients simultaneously.
- 11 -
2.1.2 Palm Computer
The user interface to the system is a Palm Computer (Palm M100). This device uses Palm
OS version 3.5. Data transfer between the Palm device and the server is established via a
serial RS232 connection.
2.1.3 Atmel Microcontroller
An Atmel Microcontroller is used to control and synchronize data transfer between the
MP3 decoder and the Bluetooth module. In this project, we needed to have two UARTs,
SPI, I2C, large program memory, 8 MHz, low power. After a thorough research, we
decided that the Atmega128L was the best microcontroller that fit our needs. The
ATmega128 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced
RISC architecture. By executing powerful instructions in a single clock cycle, the
ATmega128 achieves throughputs approaching 1 MIPS per MHz allowing the system
designer to optimize power consumption versus processing speed. It’s advanced RISC
Architecture contains about 133 Instructions most of which are single clock cycle
execution, 32 x 8 general purpose working registers plus peripheral control registers. See
figure below.
- 12 -
Fig.6 ATmega128 Microcontroller
2.1.4 MP3 Decoder
The MP3 files are typically created by converting large files from music cd’s hence
shrinking to extremely small file sizes while maintaining the audio quality. An MP3
encoder is used to achieve this goal. Therefore, in order to player MP3 files one must
decode this file. As our decoder, we chose to use the STA013 MP3 decoder. This
decoder can operate in several different modes. We used the Multimedia Mode for our
project. In this mode, the STA013 automatically detects the bitrate of your MP3 data, and
gives you a signal requesting more data. Data is then feed into the STA013 as rapidly as
possible (up to 20 Mbit/sec), while the chip keeps asserting its data request signal. The
MP3's sample rate (32, 44.1, 48 kHz) is also automatically detected, and the correct clock
and data waveforms are created for the digital to analog converter. It is possible to ask the
- 13 -
STA013 what it has detected while it's playing, though that's outside the scope of our
application. As bits are transfered, the decoder will end the request when its buffer is
nearly full.
The STA013 is designed so that when the chip requests more data, the data source needs
to respond in a timely manner, and feed the data in as rapidly as possible until the
STA013 de-asserts its request signal. The chip will make requests more frequently at
faster bitrates. The combination of time response and data rate, if they are slow, may limit
the maximum bitrate that can be played. Most VBR encodings only use fast bitrates (256
and 320 kbps) for brief times, so in many cases the STA013's input buffering allows a
design that couldn't supply 256 kbps constant bit rate to play variable bit rate files which
contain brief bursts at these high speeds.
The STA013 typically ignores non-MP3 data (producing no sound), so it's safe to feed
entire MP3 files, which may contain ID3 tags, into the STA013 without concern for
which part of the file is MP3 bitstream and what portion is the ID3 tag. The chip will just
keep requesting more data until it sees valid MP3 information. It's also safe to feed
damaged MP3 streams into the STA013, for example truncated files due to partial
download. Most damaged MP3 data is completely ignored. Some damaged files will
produce a brief chirp sound (usually depending on what follows immediately after the
damaged part), but the STA013 will rapidly sync back to good data that's sent after a
corrupted part.
- 14 -
Fig. 7: Connection of STA013 and CS4334
2.1.5 Digital to Analog Converter
A digital to analog converter is needed in the system to convert the digital signals from
the MP3 decoder to analog audio signals for output to the headphones. It is possible to
configure the STA013 to work with many different DAC chips and crystals, but we chose
to use a 14.7456 MHz crystal, which is inexpensive and a standard value (that also
happens to be an exact multiple of standard baud rates). The CS4334, provides excellent
quality line-level audio output, and also includes 4X interpolation and a continuous time
analog output filter that eliminates the need for external opamps and complex output
filtering. The CS4334 makes it simple and easy to obtain excellent quality line-level
audio output without adding noise. The CS4334 is fairly easy to use, 4 pins are digital
input, 2 pins for the outputs, and 2 pins for 5 volt power. The input format is I2S format,
which is one of the well supported formats available from the STA013 MP3 decoder
chip. For use with the STA013, the pins 1-4 of the DAC connect direct to pins 9-12 on
the STA013 (fig 8 ).
- 15 -
Fig. 8 Connection of CS4334 to Audio Output
2.1.6 Bluetooth Module and Server PC
Two Ericsson Bluetooth transmitter/receivers are used in the design. The modules are
responsible for wireless data transfer between the client and server machines.
The Server PC could be any computer with a Bluetooth USB connection and necessary
driver and interface software installed. For the server software, includes Microsoft Visual
C++ v6.0 running on Windows 2000 platform and utilizes MFC (Microsoft Foundation
Classes) and Win32.
2.1.2 Software Design
2.1.2.1 Programming ATmega128 MCU
- 16 -
Compiler used is the IAR C/EC++ Compiler. The program structure consists of a basic
interrupt driven C program (fig. 9). It starts out with initialization routines. Then a large
continuous while loop constantly runs. Within this loop, interrupts dictate certain
functions to be called. The goal is to receive a byte of data from Bluetooth, send this out
to the STA013 decoder chip. This routine is repeated until a seperate interrupt ends
occurs thus causing a termination. This interrupt may be a song change for
example. Upon occurrence of the interrupt, functions needed to operate with the Palm
interface are then called.
To summarize, the entire system is basically one huge continuous loop. This loop can be
interrupted to call certain functions (functions with the MP3 end, or functions with the
Palm control end). To overcome potential problems with UART speed on the MP3
side,we are employing the double speed feature of the Atmega128 MCU. The figure
below shows a flow chart for the MCU program. Processes utilized within this flow chart
are shown in figures 10, 11 and 12.
2.1.2.1.1 MCU Process for Palm
The main task of this process is to determine whether or not data resides on the UART
buffer. If data is present, the process checks the value of this data, interrupts the MCU
and run “PLAY”, “STOP”, “PAUSE” or “STOP” processes according to the value
received. On the event of no data, the process loops continuously till data arrives on
UART buffer.
2.1.2.1.2 MCU Process for STA013
The first task of this process is to initialize the STA013 using the I2C protocol . The
process loops continuously till proper initialization of the decoder chip is achieved. The
next step is to start sending MP3 data using SPI. MP3 data is then sent until the STA013
buffer becomes full
2.1.2.1.2.1 STA013's use of the I2C protocol
Data transfer for the STA013 MP3 decoder chip uses the Serial Peripheral
- 17 -
Interface, SPI. However, the STA013 is controlled and initialized using the I2C
protocol.
Play, pause, volume and initialization are all features that are controlled and manipulated
with the I2C protocol. To initialize the STA013 over 2000 data/address pairs are
required to be written to the chip. Once this is done and aknowledgement is sent back. If
the acknolwedgment isn't received, the chip has not been initialized and will not work.
I2c protocol, or TWI as the AtMega128 aliases it, was developed by Phillips. It is a 2wire interface, SDA and SCL. In essence it allows for a network of IC's. Each IC is
either a slave or a master. In the Wireless MP3 Project, the AtMega128 is always the
master and the STA013 is always the slave.
Each time a data bit is transfered using I2C, it is accompanied by a clock pulse. It is
initialized by a START condition and terminated by a STOP condition. Until a STOP
condition is reached, no other master can seize operation. Address packets on the I2C
bus are 9 bits. 7 address bits, a control bit, and an acknowledge bit. The AtMega I2C, or
TWI, is interrupt based. Interrupts occur after all events. See flow chart on STA013 for
implementation.
2.1.2.1.2 MCU Process for Bluetooth
In this process the program loops until data is present on the bluetooth buffer. It then
checks the format of the data. If it is text data, it to the Palm device. If MP3 data, it sends
it to the STA013 for further processing.
- 18 -
Fig. 9 MCU Program Structure
- 19 -
Fig. 10 MCU Process for Palm
- 20 -
.
Fig. 11 MCU Process for STA013 MP3 Decoder
- 21 -
.
Fig. 12 MCU Process for STA013 Bluetooth Module
- 22 -
2.1.2.1 Programming the Palm M100 Interface
The Palm application was written in the C programming language using the Palm OS
API. A GNU C Compiler was used to compile the software for the Palm application.
Another compiler used was the PilRC v2.9. This is a resource compiler used to compile
resouce scripts (layout of buttons, listboxes, etc. on the Palm's display). Resource scripts
need to be compiled to binary before linking everything together with GCC.
The Palm application acts as the human interface to the client device. When the user
interacts with the Palm application, commands are sent to the microcontroller via the
Palm's serial port. The microcontroller does all of the work involved with sending and
receiving data to and from the Bluetooth device and sending data to the MP3 decoder
chip; the Palm simply tells the microcontroller what to do and when to do it.
When the Palm application is first started (user clicks the music icon labelled "BT
MP3"), a command is sent to the microcontroller indicating that it should attempt to
connect to the server via the Bluetooth connection. When the application exits, a
command is sent to the microcontroller indicating that the Bluetooth connection is no
longer needed. The commands are sent to microcontroller in the form of unsigned 8-bit
integers as describd below:
command
8-bit command code
handler function
------------------------------------------------------------FORM_OPEN
0x06
OnEvent_FormOpen
FORM_CLOSE
0x07
OnEvent_FormClose
When a FORM_OPEN command is issued, the application waits for the microcontroller
to respond with a confirmation message before continuing. Upon receiving the
connection confirmation message, the Palm will receive a list of songs available on the
server (see fig. 13).
- 23 -
Send FORM_OPEN co mmand to
MCU. MCU will establish
Bluetooth connection.
Application Start
Wait for MCU to confirm Bluetooth
connection established.
Download playlist from server.
STATE_READY
Play
Send PLAY command to MCU.
Send 16-bit playlist index to MCU.
Previous
Decrement
playlist index.
Next
STATE_PLAYING
Stop
Increment
playlist index.
Pause
Exit
Send STOP command to MCU.
Play
STATE_STOPPED
Exit
Send PAUSE comand to MCU.
Stop
STATE_PAUSED
Play
Exit
Application Exit
Send FORM_CLOSE command to
MCU. MCU will terminate
Bluetooth connection.
Fig.13 Flow Chart for Palm Appication
Once the microcontroller establishes a connection with the server via Bluetooth, there are
five possible commands that can be sent to the microcontroller: PLAY, PAUSE, STOP,
NEXT, PREVIOUS. The commands are sent to microcontroller in the form of unsigned
8-bit integers as describd below:
- 24 -
command
8-bit command code
handler function
------------------------------------------------------------PLAY
0x01
OnEvent_Play
STOP
0x02
OnEvent_Stop
PAUSE
0x03
OnEvent_Pause
NEXT
0x04
OnEvent_Next
PREVIOUS
0x05
OnEvent_Prev
In the case of a PLAY command, a signed 16-bit integer is sent following the command
code indicating which song on the playlist is currently selected.
The user interface presents the user with five control buttons (play, pause, stop, next
song, previous song) and a playlist of available songs. The PLAY button causes song
currently selected in the playlist to begin playing. The STOP button will stop a song from
playing, while the PAUSE button will halt playback and allow the user to continue with a
PLAY command. The NEXT and PREVIOUS buttons can be used to skip playback to
the next or previous song on the playlist.
The Palm application also incorporates the physical hard buttons on the Palm device into
the user interface. The up/down hard button can be used to scroll through the playlist.
Hard button #1 (left-most button) performs that same function as the PREVIOUS control
button, while hard button #4 (right-most button) performs the same function as the NEXT
control button. Hard button #3 is a play/pause toggle that performs the functionality of
the PLAY and PAUSE control buttons. Hard button #2 is synonymous to the STOP
control button.
The Palm application is an event driven system. Any input "event" that occurs within the
program is put onto an event queue and processed, in the order received, by an event
handler loop.
- 25 -
PilotMain is the main program entry point. This starts the application's main event loop,
AppEventLoop, which handles all events that are placed on the event queue. Events that
belong to the application (as opposed to operating system events) are then passed to
AppHandleEvent. AppHandleEvent determines which form (if the application uses
multiple forms) the event belongs to and passes the event to the appropriate form's event
handler – MainFormHandleEvent.
MainFormHandleEvent determines exactly what caused the event and calls the
appropriate handler function to respond to the event. A listing of event handler functions
and their origin are described below:
Handler Function
Cause
--------------------------------------------------------------OnEvent_FormOpen
Application started
OnEvent_FormClose
Application exit
OnEvent_Play
User taps PLAY control button
OnEvent_Stop
User taps STOP control button
OnEvent_Pause
User taps PAUSE control button
OnEvent_Next
User taps NEXT control button
OnEvent_Prev
User taps PREVIOUS control button
OnEvent_HardButtonUp
User pressed scroll button UP
OnEvent_HardButtonDown
User pressed scroll button DOWN
OnEvent_HardButton1
User pressed hard button 1
OnEvent_HardButton2
User pressed hard button 2
OnEvent_HardButton3
User pressed hard button 3
OnEvent_HardButton4
User pressed hard button 4
The application must be aware of the current play-state of the entire system. The
application keeps track of the play-state in a global vaiable called gPlayState. Possible
states are listed below:
state
value
condition
----------------------------------------------------------------------STATE_READY
0x00
Ready for user input
STATE_PLAYING
0x01
Currently playing a song
STATE_STOPPED
0x02
No song playing
- 26 -
STATE_PAUSED
0x03
A song has been paused, able to continue
The global variable gCurrentSong keeps track of the playlist index of the song that is
currently playing if in STATE_PLAYING, or set to -1 if not in STATE_PLAYING.
gPlaylist is an array of null-terminated character strings that contain the list of songs
available on the server. Below is a screen capture of the Palm GUI application.
Fig. 14 Palm Application User Interface
- 27 -
2.1.3 Server Programming
The Bluetooth MP3 Server software was developed using the Microsoft Foundation Class
library to create the user interface and the Ericsson Bluetooth PC Reference Stack to
communicate with the Bluetooth device. The software was written in the C++
programming language and compiled with Microsoft Visual C++ 6.0. The MP3 server
runs on the Microsoft Windows family of operating systems.
The server application software is an event-driven system. Events can be generated by the
Bluetooth device or by the user via the user interface. These events are mapped into the
server application's message queue where they are processed by specific event handler
functions.
The server application does not interface directly with the Bluetooth device, however.
The application relies on a separately running process, BT_COMServer, that acts as a
proxy when passing messasges to and from the Bluetooth device. Bluetooth messages are
passed between BT_COMServer and the server application via a set of Component
Object Model (COM) interfaces.
The server's MP3 playlist is implemented as a linked list of file objects. When new
entries are added to the playlist, the corresponding MP3 files are opened and added to the
tail of the linked list. The playlist is implemented as a linked list instead of an array
because it must accommodate the removal of entries that exist in the middle of the
playlist without affecting the order of playlist entries. It is essentail that the order of the
files in the linked list matches the order of entries in the playlist, or else the selected song
may not match the user's selection.
The Service Discovery Protocol (SDP) is used when the client device first establishes a
connection with the server application. When the Service Discovery transaction takes
place, the server application will act as a Service Discovey server, and the client device
will act as a Service Discovery client. For the sake of simpliciy, the server will offer only
one service record containing only one service attribute. The service attribute is
implemented as a service ID containing a 128-bit UUID (Universally Unique Identifier)
- 28 -
specific this project. The client device will not attempt to establish an RFCOMM
connection if it does not find this unique service attribute.
Once the client device discovers the MP3 Server via SDP, an RFCOMM connection is
established between the client and server. The server application will accept two types of
service requests from the client via the RFCOMM channel: MP3 data packet requests and
song selection requests. Upon receiving an MP3 data packet request, the server will
create an optimally sized packet of MP3 data by reading the currently selected MP3 file
in the playlist and send this data to the client via the RFCOMM channel. A song selection
request is accompanied by a signed 16-bit signed integer. When a song selection request
is received, the server will update the playlist index with the 16-bit number associated
with the request. The proceeding MP3 data packet request will be serviced at the
beginning of the file indexed by the newly updated playlist index. A flow chart showing
the different process of the application is shown below.
- 29 -
Initialize Bluetooth Device
Application Start
Activate MP3
Server
Deactivate MP3
Server
Start
Stop
Waiting for events
Connection
Request
Exit
Song Selection
Request
Establish Connection
Update Playlist
Index
Yes
No
MP3 Server Active?
MP3 Packet
Request
Read MP3 Data
From File
Application Exit
Send MP3 Packet to
Remote Client Device
Fig. 15 Flow Chart for Server Program
2.2 Implementation
2.2.1 Overview
The Bluetooth Wireless MP3 Player Server allows the user to create a playlist of MP3
files that will be available for use by the client device. Once a wireless connection is
established between the server application and the client device, the server will respond
to requests received from the client. The client device may request a copy of the next
- 30 -
pending MP3 data packet in the data stream, or it may request the server to begin
streaming a different MP3 file in the playlist.
2.2.2 User Interface
The server application provides the user with an easy to use graphical, mouse-driven
interface. The user can add and remove MP3 files to and from the playlist, activate and
deactivate the MP3 server, as well as monitor Bluetooth events that take place between
the client device and server application.
Fig. 16 Server Screenshot 1
The top section of the server application's user interface displays the name and address of
the local Bluetooth device. When a physical data connection is established with the client
device, the name and address of the remote client will also be displayed. The fields at the
right inform the user whether or not the MP3 server is actively responding to requests
received from the client, and whether or not there exists an active data connection
between the server and client.
- 31 -
The functions of the user interface are described below:
2.2.2.1 Playlist
The large listbox in the center of the user interface is the playlist of MP3 files that are
made available for playback by the client device. The playlist presented on the Palm
interface will match this playlist exactly.
2.2.2.2 Add Files to Playlist
The Add Files to Playlist button allows the user to add MP3 files to the playlist. When
this button is clicked, a standard file dialog box appears allowing the user to select
multiple MP3 files that are stored on the user's hard drive. The selected files will be
added to the playlist.
Fig. 17 Server Screenshot 2
2.2.2.3 Remove Selected
When certain songs in the playlist are no longer desirable, a selection of songs can be
removed from the playlist. To remove songs from the playlist, the user highlights the
unwanted songs in the playlist by clicking the entry with the mouse cursor. Clicking the
Remove Selected button removes the selected MP3 files from the playlist. Multiple
playlist entries may be selected.
- 32 -
2.2.2.4 Initialize Bluetooth Device
Before the MP3 server can be activated, the Bluetooth device must be initialized with the
appropriate settings. Once the Bluetooth device is initialized, the Start MP3 Server option
becomes available.
2.2.2.5 Start MP3 Server
This button activates the MP3 server. When the MP3 server is activated, the server
application will respond to all request received from the client device. The user is
prevented from adding or removing files to and from the playlist while the MP3 server is
active.
2.2.2.6 Stop MP3 Server
The Stop MP3 Server button deactivates the MP3 server. When the MP3 server is
deactivated, any existing data connection will be cut off, and all connection requests will
be rejected.
2.2.2.7 Bluetooth Event Monitor
The Bluetooth Event Monitor field allows the user the monitor events that occur within
the system. Messages will appear in the event monitor listbox indicating the occurrence
of important events such as: successful initialization of the local Bluetooth device,
activation of the MP3 server, connection establishment, service requests received from
the remote client device, etc. This feature was originally implemented for debugging
purposes, however, it has been incorporated into the final version for the benefit of the
technically inclined user.
2.2.1 Wireless MP3 Player; Prototype #1
Our first version of the wireless MP3 player consists of a STA013 MP3 decoder chip,
responsible for decoding the MP3's. Code for this decoder chip was written in the C
language. The display interface provides means for the user to access a listing of the
songs (or other audio) residing on MP3 server. An “Analog to Digital” converter was
used to convert the decoded MP3 digital signal to an analog signal. This signal is then
- 33 -
sent to headphones so the user can listen to the MP3 he or she chose. The client also
contains a microprocessor to control and synchronize activities within the client and its
Bluetooth module, with the help of the client’s application software. The figure below
shows the first prototype of our wireless MP3 player in operation.
fig. 18 Wireless MP3 Player, Prototype v1.0
- 34 -
2.2.1.1 Project Cost
The entire project was designed and implemented for less than $90.00. The exact cost of
the components used is listed below.
AtMega128L
SRAM IS63LV1024-10J
STA013
CS4334 DAC
MAX233 (qty: 2)
Passive Components
Headphones
$17.00
$2.50
$20.00
$5.00
$11.00
$20.00
$15.00
Total Cost
$90.50
2.3 Verification & Testing
2.3.1 Test Plan
2.3.1.1 Test Case 1.1.2.1 Client response to operator commands
Unit being tested: SELECT, PLAY, PAUSE, SKIP, CANCEL commands.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.2 Test Case 1.1.2.2 Wireless Bluetooth transmission
Unit being tested: Client to server Bluetooth transmission
Test Items:
Input:
Expected Output:
- 35 -
Actual Output:
Discrepancies:
2.3.1.3 Test Case 1.1.2.3 Multiple client functionality
Unit being tested: Server response to multiple client request.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.4 Test Case 1.1.2.4 SELECT command
Unit being tested: Server response SELECT command.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.5 Test Case 1.1.2.5 PLAY command
Unit being tested: Server response PLAY command.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies
2.3.1.6 Test Case 1.1.2.6 PAUSE command
Unit being tested: Server response 1st instance of PAUSE command.
Test Items:
Input:
- 36 -
Expected Output:
Actual Output:
Discrepancies:
2.3.1.7 Test Case 1.1.2.7 PAUSE command
Unit being tested: Server response 2nd instance of PAUSE command.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.8 Test Case 1.1.2.8 SKIP command
Unit being tested: Server response SKIP command.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.9 Test Case 1.1.2.9 CANCEL command
Unit being tested: Server response CANCEL command.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.10 Test Case 1.1.2.10 Error processing
Unit being tested: Server generation of error report.
Test Items:
- 37 -
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.11 Test Case 1.1.2.11 Transmitted MP3 data format
Unit being tested: Client’s accepted MP3 data format.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
2.3.1.12 Test Case 1.1.2.12 MP3 audio signal
Unit being tested: Client MP3 audio signal.
Test Items:
Input:
Expected Output:
Actual Output:
Discrepancies:
discepancy
- 38 -
3.
Summary
MP3 players in today’s market have a major limitation; the amount of MP3 music
accessible to the listener is limited to the device’s physical memory or storage
capabilities. Our wireless MP3 player eliminates this limitation by providing the home
user unlimited real-time access to his/her entire MP3 library collection. This device is
very unique, especially since wireless MP3 players do not exist. It uses Bluetooth
wireless technology to transmit data from a PC server to a small hand-held unit. This
hand-held unit gives the user key features such as song play list, rewind, forward and so
on. We have successfully implemented a Bluetooth protocol stack on an Atmel AVR
microcontroller, coupled with an MP3 decoder chip to playback CD quality MP3 files at
a sampling rate of 128 kb/s.
With further development, this wireless MP3 player could become a key element in a
user’s personal area network. It could be developed to interface with all audio and data
dependent devices such that the user could be able to answer phone calls from the home
telephone line, listen to answering machine, see the phone number of incoming calls,
receive email alerts and so on.
- 39 -
4. References
[1]
Bray J, C. Sturman, Bluetooth 1.1: Connect Without Cables, 2nd Edition, Prentice Hall, Upper
Saddle River, NJ, 2001.
[2]
Miller B.A, Bluetooth Revealed, Prentice Hall, Upper Saddle River, NJ, 2001.
[3]
Miller M, Discovering Bluetooth, Sybex, San Francisco, 2001.
[4]
Bray J, B. Senese, Bluetooth Application Developer's Guide, Syngress Publishing, Rockland,
Mass. 2001.
[5]
Held G, Data over wireless networks: Bluetooth, WAP, and wireless LANs, McGraw Hill,
New York, 2001.
[6]
Muller N.J, Bluetooth Demystified, McGraw Hill, New York, 2001.
[7]
Siep T, An IEEE Guide: How to Find What You Need in the Bluetooth Spec, IEEE Press, New
York, 2001.
[8]
Tranter W.H (Ed.), Wireless Personal Communications: Bluetooth Tutorial and Other
Technologies, Kluwer Academic Publishers, Boston, Mass., 2001.
[9]
Bluetooth Special Interest Group (SIG), http://www.bluetooth.com.
[10]
Dreamtech Software Team, Cracking the Code: WAP, Bluetooth, 3G Programming, Hungry
Minds, New York, 2002.
[11]
Rhodes N, J McKeehan, Palm OS Programming: The Developer's Guide, O'Reilly &
Associates Sebastopol, California, 1998.
[12]
Kruglinski D, G Shepherd, S Wingo, Programming Microsoft Visual C++, 5th Edition,
Microsoft Press, Redmond, Washington, 1998.
[13]
Prosise J, Programming Windows with MFC, 2nd Edition, Microsoft Press, Redmond,
Washington, 1999.
[14]
Rogerson D, Inside COM: Microsoft's Component Object Model, Microsoft Press, Redmond,
Washington, 1997.
[15]
Marshall B, Win32 System Services 2nd Edition, Prentice Hall, Upper Saddle River, NJ, 1996.
[16]
Stroustrup B, The C++ Programming Language, Special Edition, Addison Wesley, Upper
Saddle River, NJ, 2000.
[17]
The Bluetooth Specification, http://www.bluetooth.com.
[18]
The Palm OS online API reference, http://www.palmos.com.
[19]
Paret D, C Fenger, The I2C Bus From Theory to Practice, John Wiley & Sons, West Sussex,
England, 1997.
- 40 -