University of Waterloo

Faculty of Engineering
The Department of Electrical & Computer Engineering

E&CE Fourth Year Design Project Final Report

For

MCS Network Module

Group Project ID: 2004.047

This report is submitted as the design sign-off/audit report requirement for the ECE.492A
course. It has been written solely by us and has not been submitted for academic credit
before at this or any other academic institution.

Presented By

Robert (YJ) Cha 99156967

Dave Shenton 99044462
Tae Ho Yoon 99270603

Faculty Consultant: Prof. George H. Freeman

January 5, 2004
Abstract

As more people see the advantages of “connected” appliances, more manufacturers have
been jumping on the bandwagon to develop them towards a complete home network. The
intent of this project was to develop a standard module that easily and affordably integrates
into currently existing AV products. The module allows media on a device to be exposed
and transferred over a home local area network using a new standard called UPnP. Many
devices are being developed to meet these ends using a central media hub, however this
module has the advantage of being a satellite in a distributed and non-centric system.

ii
Acknowledgements

For the proposed fourth year design project, the “MCS Network Module” group
acknowledges Professor George H. Freeman for his dedication as the consultant of the
project. His periodic assessment of the project with his guidance on several design issues is
a valuable asset for the group. The “MCS Network Module” group is grateful for his
consideration and his valuable time devoted on the project review.

We thank Sae-Koo Lee, a senior engineer for Digeo Co., and Ray Schuder, a senior
engineer for NVIDIA Co, for their technical feedback on both software and hardware issues
of home network and home entertainment systems.

We also thank E&CE Department for their monetary contribution that will be spent in
purchasing any hardware component.

iii
Glossary of Terms and Acronyms

Analog: Characteristic of being continuous valued and continuous time

ADC: Analog to Digital Converter: takes a continuous analog signal and

outputs the equivalent signal in digital PCM format

Bandwidth: The difference between the upper and lower cut-off frequencies

Control Points: The UPnP device responsible for control of

other devices and user interaction

DAC: Digital to Analog Converter: takes a pulse code

modulated digital input signal and outputs the
analog equivalent

Digital: Characteristic of being discrete valued and discrete time

Ethernet: A communication protocol allowing full duplex data communication

over CAT 5 twisted pair cable.

GUI: Graphical User Interface: a user interface that is implemented using

graphics to provide visual feedback to the user in the form of graphics
objects rather than text

HTTP: HyperText Transfer Protocol.

Linux: An open source operating system based on the UNIX operating

system

MCS: Media Control Satellite

Media: Any form of data that represents audio, video or graphical

information

MP3: MPEG Layer 3: A lossy compression standard that is popular for

audio files.

.NET: A Microsoft software platform that supports user applications

PDA: Personal Digital Assistant: A handheld organizer computer

iv
Renderer: A device that takes information and presents it to the physical world.

RTP/RTSP: A Real-Time Streaming Protocol.

Sampling: The process of recording values of a continuous signal at fixed

intervals.

SDK: Software Development Kit: libraries and documentation to provide

functionality to the software developer.

Streaming: Regulated, real-time transfer of data

SWIG: Software Wrapper Interface Generator: software development tool

that connects programs written in C/C++ with a variety of high-level
programming languages. SWIG is primarily used with common
scripting languages such as Python.

TCP/IP: Transfer Control Protocol/Internet Protocol: The protocol by which

packets are sent over the network

UI: User Interface: the point of user interaction.

UPnP: Universal Plug and Play: A standard that describes how network
devices can be automatically detected and controlled.

WAV: An audio file type that consists of PCM data for left and right
channels interleaved word by word.

v
 Table of Contents

Abstract ..................................................................................................................... ii
Acknowledgements .................................................................................................. iii
Glossary of Terms and Acronyms ............................................................................ iv
List of Figures ........................................................................................................... viii
List of Tables ............................................................................................................. ix
1. Introduction .......................................................................................................... 1
2. Design Process ...................................................................................................... 2
2.1. Customer Requirements .......................................................................... 2
2.1.1. Performance Requirements .......................................................... 2
2.1.2. Audiences ..................................................................................... 2
2.2. Design Project Plan and Milestones ........................................................ 3
2.2.1. Design Project Plan ...................................................................... 4
2.2.2. Tasks ............................................................................................. 4
2.2.3. Design Flow Specifications .......................................................... 4
2.3. Function Specifications ............................................................................ 5
2.3.1. Hardware Functional Specifications ............................................. 5
2.3.2. Software Functional Specifications .............................................. 5
2.4. Design Specification and Verification ..................................................... 6
2.4.1. Design Verification - Software...................................................... 6
2.4.1. Design Verification - Hardware .................................................... 6
2.5. Prototype Construction ............................................................................ 7
2.5.1. Software......................................................................................... 7
2.5.1.1. UPnP Applications – Control Points ............................... 7
2.5.1.2. UPnP Applications – Devices ......................................... 7
2.5.1.3. GUI Application .............................................................. 8
2.5.2. Hardware ....................................................................................... 8
2.6. Testing and Verification of Prototype ...................................................... 8

vi
 2.6.1. Prototype - Software...................................................................... 8
2.6.2. Prototype - Hardware..................................................................... 9
3. Design Changes .................................................................................................... 10
3.1. Hardware Design Changes ...................................................................... 10
3.1.1. Design Trade-Offs ...................................................................... 10
3.2. Software Design Changes ........................................................................ 10
4. Design Audit ......................................................................................................... 12
4.1. Project Consultant Demonstration ........................................................... 12
4.2. Responses to Project Consultant’s Suggestions ...................................... 12
4.2.1. Verification of Customer Requirements ..................................... 12
4.2.2. Verification of Implementation Details....................................... 13
5. Future Development ............................................................................................. 14
5.1. Problem – Slave Output Mode ................................................................ 14
5.2. Problem – Python Callback ..................................................................... 14
Appendix A: Customer Requirements ...................................................................... A-1
Appendix B: Design Project Plan and Milestones ................................................... B-1
Appendix C: Functional Specifications .................................................................... C-1
Appendix D: Design Specifications ......................................................................... D-1
Appendix E: Verification Plan ................................................................................. E-1
Appendix F: Test Plan for the Constructed Design Prototype ................................. F-1
Appendix G: Paper Design Verification Data .......................................................... G-1
Appendix H: Prototype Test/Measurement Data ...................................................... H-1
Appendix I: Design Flow ......................................................................................... I-1
Appendix J: Consultant Sign Off Form and Memo .................................................. J-1

vii
 List of Tables

Table 1: Project Milestones and its Completions ..................................................... 3

Table 2: Gating Functions ........................................................................................ 4
Table 3: Hardware Design Changes ......................................................................... 9
Table 4: Software Design Changes .......................................................................... 9

viii
 List of Figures

Figure 1: Relationship between Control Point Software components....................... 7

Figure 2: Relationship between Devices Software components ............................... 8

ix
1. Introduction

The MCS Network Module, an integrated component of a consumer electronic device

to provide the network connectivity along with other network-based functionalities, was
successfully built to meet the expected requirements. This design project, consisting of
both hardware and software design and implementation, was systematically conducted
with respect to well-organized milestones, thus completing all the primary requirements.

This final report addresses the design and implementation processes with a clear
indication of design process specification. More precisely, design process identifies the
main design/implementation steps with respect to the design state flow diagram designed
beforehand from customer and functional specifications. In this process, gating functions
and their specific output such as design completion and changes are discussed. As a
result, the design flow is analysed within the perspective of attaining the primary
requirements of the following stages (further details in Appendix):

• Customer Requirements
• Design Plan & Milestones
• Functional Specification
• Design Specifications
• Verification Plan
• Test Plan

Specifically, this report is an assessment of the current project’s completion status

with the examination of project requirements and the demonstration of its feasibility,
finally leading to the design audit. Indeed, all design issues, as well as functional
specifications, were validated with specific decision decisions with respective trade-offs
and thus supported by various verification/testing methods, nonetheless assuring a
successful prototype building. Finally, the demonstration of the prototype in front of our
faculty consultant, as well as his subsequent evaluation, further delivers the quality
assurance of the built prototype and the successful completion of the fourth year design
project.

Page 1 of 14
2. Design Process

The overall design process was conducted in the following order:

• Customer Requirements
• Design Project Plan and Milestones
• Functional Specification
• Design Specification and Verification
• Prototype Construction and Verification

2.1 Customer Requirements

The “MCS network module” is a small unit that can be installed in an electronic
device, to provide Ethernet connectivity between audio and video consumer electronics
devices such as CD players and stereo amplifiers with minimal integration effort on the
part of manufacturer. The detailed customer requirements can be found in Appendix A.

As a result, the module must contain all the communication functionalities, and must
expose universal interfaces for controlling and communicating with other devices. The
primary customer requirements for the module are as follows:

• Provide network connectivity to a consumer device

• User-controlled and coordinated media streaming
• Easy and simple (automatic) device installation
• User-friendly interface for device operation

2.1.1 Performance Requirements

Besides supporting the customer’s required features, the module must comply with
the performance specifications, the qualitative measurement of customer requirements.
These respective specifications for the customer requirements are:

• 10 Mbps connection from a standard RJ-45 connector

• Audio Quality
• UPnP Implementation
• Intuitive and interactive Graphical User Interface
• Minimum size and cost

2.1.2 Audiences

The customers, to whom the module is intended for, are the manufacturers of
consumer electronic devices. Although the long term goal of the customer is to integrate
this module in most, if not all, future electronic devices, which comprise entertainment
systems and/or home appliances, the designed prototype will incorporate only audio
features; thus targeting the manufacturers of audio devices.

Page 2 of 14
2.2 Design Project Plan and Milestones
The tasks involved in the design and prototyping of the MCS module system include
the communication module, the analog converter, the UPnP control point application,
the media server and renderer applications, which coordinates media streaming, and
graphical user interface to the system (from both PC and PDA, which is optional for
future development and not implemented for current report). Please refer to Appendix B
for further detailed description of development tasks, as well as description of revised
milestones.

Table 1: Project Milestones and its Completion

Milestone Description Completion(Y/N)
Execute Verification Execute Verification Plan to ensure that Y
Plan design concept works, before
implementation
Documentation: Remaining Appendices for future reports, Y
Functional Specs, Interim and Sign-Off, and their completion
Verification Plan, as well.
Test Plan, and
Design Specs,
Interim Report,
Sign-off Report
Develop main Setup of the embedded development board Y
embedded board
Design system Procure a minimal Linux kernel and compile Y
software solution it to run on the micro-controller. Develop
(Linux kernel and drivers to support the analog module.
drivers)
GUI Prototype An implemented GUI resembling the drawn Y
design (possibly with minimal functionality)
Complete All All hardware components are implemented Y
Hardware and verified, including the analog module
implementation
Implement UPnP UPnP is completely implemented and all Y
necessary relevant programming is
completed
Tested, verified, The final product result (final integration). Y
properly functioning
MCS network
module
Sign-Off Report Design Audit report, explains Y
success/failures of MCS network module and
confirms if the prototype is ready for
production.
Final Report Overall description of design process Y
throughout the duration of the project.

Page 3 of 14
2.2.1 Design Project Plan

For efficient management of project, the “MCS network module” group, composed
of three members, have set a plan for the project specific development stage, and also a
plan specific to each member. Furthermore, the project milestones are detailed to ensure
that the project completion date is met. The detailed Project Plan and Milestones can be
found in Appendix B.

Table 2: Gating Functions

Gating Function
Upnp Software Verify
GUI Design Verify
Analog Board Meet Req’s
Complete System Meet Req’s
Description
Verifies that the UPnP system performs all the
functionality that was laid out in the design
specification. This includes operation of the services
within the devices.
Ensures that the GUI meets the functional
specifications as far as operation and extent of user
control.
The Analog board must perform as laid out in the
functional specification before advancing.
This final gating function is a checkpoint where we
ensure that all customer requirements have been
satisfied and that the system is free from imperfections
that may cause failure.

For further detailed description of design flow, please refer to Appendix-I.

2.2.2 Tasks

The tasks involved in the design and prototyping of the MCS module system
involve:
• The communication module
• A media server PC application
• A control point PC application
• An analog converter.
• Optional: a PDA user interface to the system

2.2.3 Design Flow Specification

The flow of the design process for this project was not very linear due to the fact that
there were many different components of software and also hardware. There were
uncertainties in the design flow, such as the delay in the shipment of the development
board and many verification stages we needed to go through in order to ensure the entire
system was operational.

The main software components of the design process are the UPnP and GUI
implementation. This is early in the flow chart since they required the most amount of
time. Also, due to uncertainties related with hardware portions, the hardware design and

Page 4 of 14
prototyping was done long before integrating with the system. For hardware, we had to
give enough of a buffer of time to allow for long lead times for delivery of hardware
components.

In terms of our design flow path, although the final integration task involved
simultaneous combination of hardware and software, the fact that software was
implemented into the hardware system, there were slightly different delays for the
software development parts. The software for the embedded system was completed first
due to a higher chance for complications.

2.3 Functional Specifications

Based on customer requirements and project plan, the group has formulated specific
functional specifications of the project that would simultaneously satisfy our goals from
the developer’s perspective and the customer’s demands. The functional specifications
are outlined with respect to three main perspectives: general system overview, hardware,
and software. These functional specifications address major customer requirements
using a hierarchical view of the system itself and its main components. The complete
function specification can be found in Appendix C.

In terms of general system overview, the “MCS network module” provides Ethernet
connectivity for remote control and streaming of media between module-equipped
devices, ensuring the following capabilities:

• Ethernet connectivity
• Digital/Analog conversion
• Streaming media
• Automatic device discovery and self-configuration
• Universal control of the device

2.3.1 Hardware Functional Specifications

It is important to note that the concept of “modular” design is essential for our
hardware. The division of overall system (a module) into distinct modules, each
achieving specific function, is the key attribute for distinctively classifying hardware
functional specifications with respect to a particular “modular” hardware part.

2.3.2 Software Functional Specifications

In connection to hardware functional specifications, the software functional

specifications represent both the low-level and the high-level implementation.

The module will use the Universal Plug and Play (UPnP) standard for
communication and control over Ethernet. This standard defines three devices: Media
Server, Media Renderer, and Control Point. UPnP satisfies all of the customer

Page 5 of 14
requirements pertaining to device communication and control and has the potential to
become a ubiquitous standard for media sharing.

Program modules that implement the UPnP standard will be installed. Code that is
specific to the customer application will handle the idiosyncrasies of configuring and
operating the parallel and serial control lines to communicate with the chosen electronic
device.

A personal computer will act as an UPnP media server for the prototype system. An
interactive GUI will provide a user interface to the media server. Another GUI will
provide a user interface to the control point. The graphical user interface (GUI) will be
communicating directly with a control point and so will have access to the list of all
detected UPnP devices and will be capable of requesting state variables and initiating
remote control commands. The GUI will be designed to operate in a consistent manner
regardless of the nature of the module that is being accessed or the medium on which the
GUI is implemented (PC, Palm PDA).

2.4 Design Specification and Verification

The design specifications address the implementation of the major functions defined
in the functional specifications. For the design of the each major component of the
system, key design aspects are identified in detail and any relevant engineering analysis
and/or theory is explained. A detailed design is provided for the communications board
with UPnP software, the analog module hardware and the GUI applications for user
control in Appendix D.

2.4.1 Design Verification – Software

As it can be seen from Appendix E and H, the verification plan was executed to
ensure that all the software components of MCS Network Module were feasible, and
several verification data were generated to ensure the validity of our choice. Basically,
the main pre-prototype tasks conducted before actual software implementation was
researched through various alternatives, and analysis of pseudocode to further approve
the decision taken. After various researches and consultations with experts, the pre-
implementations tasks in terms of software were successful in identifying the valid data
to approve the design.

2.4.2 Design Verification – Hardware

Since most of the hardware design conforms to industry standards, the verification
proved to be fairly simple. The component values associated with various ICs are
already tested and proven to work by the manufacturers of the integrated circuits and
those ICs were chosen to reflect the current industry standard for superior audio, such as
the 16-bit data converters and 44.1kHz sampling clocks.

Page 6 of 14
2.5 Prototype Construction
As the design specification indicated, the prototype construction proceeded
separately for software and hardware.

2.5.1 Software

The software development was divided into the UPnP applications (Control Points
and Devices) which provide the low-level management UPnP services and the high-level
GUI component which interacts with the low-level component to provide user control.

2.5.1.1 UPnP Applications – Control Points

The operation of the UPnP Control Point is coordinated by a C++ class instance,
which interfaces with the underlying UPnP API. Threads generated by the Control Point
API execute callbacks when events occur, such as advertisements and state variable
events.

The C++ component of the system maintains a list of devices that have been
discovered and exposes an interface that allows an application to view the devices and
execute actions on them. The GUI component, written in Python, communicates with the
C++ component. Only one instance of the Control Point API can exist therefore the C++
class is designed as a singleton class. Any GUI instances that are created will refer to the
same instance of the control point class.

Figure 1: Relationship between Control Point software components

2.5.1.2 UPnP Applications – Devices

As in the case of the Control Point above, the operation of the UPnP Device is
coordinated by a C++ class instance (UPnPDevice), which interfaces with the
underlying UPnP API. Callbacks are handled in the same manner and the API generates
threads. The Python component is optional and would exist for PCs that are acting as
Media Servers for example. The UPnPDevice instance maintains a list of UPnPService
instances for each UPnP service that the device supports. The UPnPService contains a
list of state variables that describe the state of the service and can be queried by a control
point. For each specific service there is a class that inherits from UPnPService and
provides additional functionality specific to the service such as the handler functions for
actions. These action handlers process the SOAP messages and raise events that allow
other functions to alter the services state. This architecture allows a number of services
in a device to interoperate with each other.

Page 7 of 14
 Figure 2: Relationship between Devices software components

2.5.1.3 GUI Application

After the UPnP implementation, the GUI was developed as such to control the low-
level processes and to display all the results in a user-friendly way. As it was previously
mentioned for the communication between the low and high level, specific UPnP
functions were processed upon receiving different callbacks from various widgets of
GUI (button, text field, display box, etc).

To ensure portability and compatibility with C++, Python was used to implement the
GUI.

2.5.2 Hardware

As per the design specifications, the analog converter module was constructed using
many of the parts that were readily available. As mentioned in the design changes
section below, design changes were needed to reflect the availability of the hardware
components.

Many issues arose during the construction of the hardware prototype, due to the fact
that there were many uncertainties associated with hardware components and human
errors associated with physical construction of the prototype. The prototype was
constructed with satisfactory results despite the sheer large number of uncertainties that
are apparent in real hardware prototypes.

2.6 Testing and Verification of Prototype

Page 8 of 14
2.6.1 Prototype – Software

After the software implementation, various verification and testing methods were
conducted, as it was described in appendix F and appendix H. Please refer to Appendix
H for test data.

2.6.2 Prototype – Hardware

Though the test results of the prototype show that the analog module is not
distortion-free, the quality of the audio signal is still acceptable. Even with the distortion
apparent in the results, the prototype meets the functional specifications.

Page 9 of 14
3. Design Changes
After the completion of the design verification plan, some significant changes were
made to the project in order to enhance the project’s feasibility, consequently altering the
expected implementation schedule. Furthermore, in light of several discoveries and
researches during the implementation stage, the design specification has also been in
effect of minor modifications for increased optimization.

There were a few minor changes made to the final design of the project. These
changes were initiated by a few design trade-offs due to several performance regressions
and ongoing issues experienced during the implementation stages. Most of the changes
were made in the software component of the project to make improvements to the final
design presented during the design audit.

3.1. Hardware Design Changes

Table 3: Hardware Design Changes

Original Task Revised Task Reason
Changed the amplifier Due to limited supply voltage, a
design specialized audio amp was used.
Added clock oscillator Design for clocking circuitry was
Analog Module
and binary counters not taken into account. Clock
Development
availability was assumed.
Added ADC circuitry Added due to similar
implementation as the DAC circuit

3.1.1 Design Trade-offs

The initial design of the analog converter did not include circuitry to accommodate
duplex operation. This decision required the need for an analog to digital converter, in
order to convert the analog audio input to digital input into the MCS module. The ADC
circuitry designs were added after the initial designs. However, the addition of the ADC
circuitry will not be utilized since the software components for the duplex operation will
not be implemented.

3.2 Software Design Changes

Table 4: Software Design Changes

Original Task Revised Task Reason
UPnP Media Server The service AVTransport was not used. Additional
Services The ConnectionManager and features were not
ContentDirectory that were specified to required to fulfill
be running on the Media Server were requirements
chosen to be only partially implemented.
UPnP Media Renderer The standard services AVTransport, Additional
Services ConnectionManager and features were not

Page 10 of 14
 RenderingControl that were specified to required to fulfill
be running on the Media Renderer were requirements
chosen to be only partially implemented.
Upnp Action / Response Actions were originally planned to be This was done to
asynchronous calls, where action simplify the
responses would generate a callback. interaction
This design was changed one using between the GUI
synchronous calls. and the control
point
Auto Update The automatic software update was not Low priority
implemented feature was
omitted due to
time constraints
HTTP Streaming For simplicity and efficiency, HTTP RTP/RTSP was
streaming was used instead of the more
proposed RTP/RTSP protocol. complicated than
required
Threads Threads are created and managed by the Functionality
Intel UPnP SDK so no development was provided by
required for managing threads. SDK
Only WAV format Only WAV format will be supported for MP3 omitted due
supported media transfer. MP3 decoding was not to time
implemented. constraints and
decoder
availability
Control Point The control point application was Palm was
Application implemented on a standard PC instead of optional
the specified Palm PDA.

The changes made have been reflected in the appropriate Appendices attached with this
report. (Please refer to the Appendices of Interim report for clear indication of changes
made)

Page 11 of 14
4. Design Audit
In terms of the modifications made to the MCS Network module, it can be clearly
noticed that the design along with design verification plan was well set. The minor
changes stated in the report are incomparable to the amount of design tasks our project
required. As it was shown through the design process, as development proceeded, all the
design issues were completed as expected, or with little delay; however, the design
project was successful in meeting the final deadline.

4.1 Project Consultant Demonstration

The Project Consultant Demonstration was held on 25th July, 2003, 9am in front of
Professor George H. Freeman. Despite the large scale of the project, all essential features
are successfully demonstrated in a modular manner in order to fully identify the
fulfillment of customer requirements, as well as strengthening design highlights.

A memo written by Professor Freeman, along with his 10 professional opinions, is

included as in Appendix J of this Sign-Off Report.

4.2 Responses to Project Consultant’s Suggestions

As indicated in Appendix J, Project Consultant has suggested some specific details

about two following issues.

4.2.1 Verification of Customer Requirements

In terms of cost feasibility, the fact that most of the designs were mainly software,
and the use of open source code such as Linux, UPnP SDKs, C/C++, gcc, and Python,
reduced the actual capital to a minimum. Thus, the purchase of AXIS developer board
and analog module components were the only cost associated with the design project,
which is approximately $300. According to resources from current manufacturers of
similar products, our budget spent was found to be less than the cost of standard
hardware parts (VIA motherboard – $500) adopted by these companies. Moreover, the
same resource informed that their actual cost requirements, which are higher than ours,
were sufficiently met in a mass-production situation. As a result, the requirement about
the cost of the module to be less than 10% of the average cost of an electronic device,
which is usually $800 for current popular stereo system, is satisfied.

In terms of minimal size requirements, the reason we specifically chose the AXIS
board was for its small form factor. The actual AXIS board’s dimensions are 11.2cm X
11.0 cm X 2.7 cm. The prototype of the analog board was constructed using parts that
were readily available, but the analog board can be produced in mass production using
smaller components on pre-fabricated PCBs, which would make the size negligible in
comparison to the overall size of a typical home entertainment device. A typical home
entertainment system is measured at approximately 50cm X 40cm X 20cm. The AXIS
development board is much smaller than a typical home entertainment system. This
verifies that our product will meet the size requirements as per the Customer

Page 12 of 14
Requirements. Since the prototype analog board and the AXIS board were constructed
for development purposes only, the size of the product will be even smaller were they to
be mass produced on custom boards.

From the beginning of the design project, the aspects of portability and flexibility
were identified as primary implementation requirements. It is for this reason why UPnP
SDKs were selected as the core part of the module. More precisely, the flexibility in
UPnP service management nonetheless improves its portability, but also allows its
compatibility with different systems, requiring different services. Thus, MCS Network
Module can simply be adapted to other consumer electronic devices such as microwave
with the addition of other services specific to the particular device.

4.2.2 Verification of Implementation Details

Since AXIS embedded board was selected for its features exactly satisfying all our
design needs, any mechanical alterations were needed. It was used exactly as it was
originally shipped.

Page 13 of 14
5. Future Development
Due to time constraint, the features identified as low-priority were not implemented.
Among those features, the use of PDA as a remote control point is a desirable feature
that could enhance the flexibility and efficiency of MCS Network Module.

Moreover, as it was mentioned before, two unexpected design problems occurred

near the end of prototype construction. However, as these problems were identified
minor to overall completion of the project, the initial design specifications were not
affected and conducted as it initially was. Although these problems still existed, the
project was completed with minor solutions.

5.1 Problem – Slave Output Mode

The synchronous serial port on the AXIS developer board does not function properly
in the Slave Output mode. In this mode, data is sent when an external clock signal is
provided. This mode is necessary to allow the PCM data to be sent to the analog module
at the proper sample frequency. It is not clear whether the problem is due to the
hardware or due to the synchronous serial port driver that was provided by AXIS
communications. However, the synchronous serial port does operate correctly in Master
Output mode, where the clock is provided by the board itself.

5.2 Problem – Python Callback

In order to allow callbacks to Python code, some coding must be done using the C
API for Python. In Python, everything is an object called a PyObject, including Python
functions. Lists are stored in structures known as ‘tuples’, which are also a type of
PyObject. The C API function ‘apply()’ calls a function using an existing ‘tuple’ as the
argument list. For some reasons, the function ‘apply’ does not recognize the ‘tuple’ as a
‘tuple’ when it contains a Python function as one of the elements in the ‘tuple’.

Page 14 of 14
 APPENDIX A
Customer Requirements

This document outlines the requirements to be met in the design and development
of the MCS network module henceforth referred to as the module. Figure A.1 below
illustrates the general scenario in which the module will play a major role in a home
network system by providing consumer electronic devices with Ethernet connectivity for
sharing of media.

A.1 Customers
The customers, to whom the module is intended for, are the manufacturers of
consumer electronic devices. The module will be installed inside consumer electronics,
such as stereo systems and CD players, thus enabling their network connectivity with
other computers, or any network-enabled devices.

Ethernet Hub

Ethernet Links

Figure A.1: General Overview

The ultimate purpose of the module installed in an electronic device, as shown in

Figure A.2, is to provide Ethernet connectivity between audio and video consumer
electronic devices such as CD players and stereo amplifiers with minimal integration
effort on the part of manufacturer. The module will contain all the communication
functionalities, and will expose universal interfaces for controlling and communicating
with devices.

A-1
 Figure A.2: Detailed Application

A.2 Customer Requirements Priority

As it was shown in Figure A.1, the ‘module equipped devices’ will operate in a
networked environment with other module equipped devices or with PCs running
appropriate software. Any new devices will be detected upon connection to the network
by means of an ‘automated discovery process.’ The module will allow digital streaming
of media in a point-to-point fashion between modules, provide information about
rendering capabilities or media available on the electronic device, and allow remote
control of the electronic device over the network.

Table A.1 is a list of desired customer requirements, in order of priority. Those

requirements labeled with priority level of 1 are the essential features of the module that
must be implemented to be acceptable. If time permits, the additional features with lower
priority levels will be implemented to contribute to the overall value of the module.

Table A.1: Prioritized customer requirements

Priority Customer Requirements
Provide network connectivity to a consumer device, by enabling Ethernet
1 capability, which would permit the consumer device to connect to computers
and/or other devices via a home network.
Allow duplex streaming of audio or video media stored on a hard disk of a
1 computer or on any other module equipped devices. Modules must be capable of
controlling devices in order to coordinate the media streaming.
Implement the UPnP interfacing protocol to embrace the gaining popularity of
1 the UPnP standard that would allow the automatic detection of any new devices
on the network.
Implement a user-friendly interface on PCs or module equipped devices that
indexes the available media files on the network and allows fast and easy
browsing of the files. The module will provide detailed information regarding the
1 media content of the device in a uniform way such that the contents can be
indexed and browsed by a user application. It will provide detailed information
regarding the type and format of media that the electronic device is capable of
rendering and the supported transfer protocols.
The module must be economically feasible both in terms of cost and labour time
1
for a manufacturer to integrate it into their existing products.
The module must have a minimal form factor to fit in existing electronics
1
enclosures without necessitating any additional mechanical alterations.

A-2
 The module shall provide a standard interface to the electronic device such that
2 manufacturers can easily integrate the module with the existing electronic
controls, and allow remote operation and serial communication.
The software must be modular so that functionality can be added as needed as per
2 the specific application. An auto-update (optional) facility must be provided that
supports automatic software updates making the module transparent to the user.
The module shall also be extensible and capable of supporting additional custom
3 features beyond the standard interface through spare configurable I/O lines. The
module must be easily extensible to support video media (optional).
Adaptable to control of other consumer electronic devices such as microwaves
4
leading to home automation solutions.

See Appendix J for the complete list of customer requirements satisfied by the design
prototype presented during the demonstration with the faculty consultant.

A.2 Customer’s Performance Requirements

Upon completion of the product, the customer will undergo a benchmarking
session, whereby the product will be tested against the performance specifications
outlined in Table A.2, in order to qualify whether the designed product meets the most
essential requirements labeled with priority of 1 in Table A.1.

Table A.2: Performance Specifications of Customer Requirements

Requirements Performance Specifications
Ethernet capability Standard 10/100 Mbps connection; must provide a standard RJ-45
connector for Cat 5 Ethernet cables.
Audio streaming Decode compressed audio signals into PCM digital formats and
convert to analog with a quality that exceeds 128 kbps stereo.
Sounds should be free of any human perceptible distortions.
UPnP Implementation UPnP SDK allows the device to automatically detect other devices
on the network and auto-configures itself to permit integration into
the existing media network.
User interface Remote capabilities should be an intuitive interface that indexes
media from all capable devices connected to the network, and
allows the user to browse through the media and control them via
the user interface.
Cost Cost of the module should be no more than 10% of the average
cost of an electronic device in which the module would be
integrated. This leads to a nominal cost limit of $80.00 CDN. It
would be acceptable if the prototype exceeded this limit provided
the system would meet these cost requirements in a mass-
production situation
Size Overall size of the module should be no larger than the size of a
standard PCI card.

A-3
See Appendix J for the complete list of customer requirements satisfied by the design
prototype presented during the demonstration with the faculty consultant.

The long term goal of the customer is to integrate this module in most, if not all,
future electronic devices. The module will provide future products with the capabilities
to be part of complete home network, which can be comprised of personal computers,
entertainment systems or home appliances.

A-4
 APPENDIX B
Design Plan & Milestones

B.1 Classification of Tasks

The overall tasks can be classified into four main categories: hardware
development, software development, overall integration, and finalization tasks.

In term of hardware tasks, the design and implementation of a microprocessor

system along with an analog module is the principal duty. The first design concern is to
develop an embedded system with Ethernet capability that allows connectivity with
multiple similar devices or PCs. The device will be required to multitask between
communications and media streaming and rendering tasks. Then, an analog module
would be designed specific to the customer requirement in terms of media capability.
The analog module will provide all necessary digital-to-analog conversions (and vice
versa) and provide the pre-amplified analog audio signal.

Secondly, the software tasks consist of programming a system software solution

using a Linux kernel and drivers on the module, with the incorporation of the UPnP
protocol in a daemon process. Besides software tasks on embedded system, there is the
development of graphical user interface and UPnP setup on the PC (and PDA [optional],
if there is a spare time after the completion of “must-to-have” components).

There is an overall integration task, which encompasses the project as a whole;

MCS module’s incorporation into an analog module, whose purpose is to simulate an
audio unit, along with the connectivity to the PC. This task will involve all group
members. However, during the week 5 (the interim report preparation), we have come to
a conclusion that integration task for design audit demonstration wasn’t essential, but the
importance was either the assurance of proper functioning of each component.
Consequently, the full integration task as well as home network setup demonstration will
be presented during the symposium.

Finalization tasks include the preparation of the required sign-off report and final
report as specified in the project contract as well as a presentation of the complete design
during the design symposium.

B-1
B.2 Tasks Assignment
The group members for “MCS network module”, and their respective duties, are:
• Tae Ho Yoon (thyoon, ID# 99270603)
Project Manager, Lead Software Development (GUI, UPnP protocol)
• Dave Shenton (dwshento, ID# 99044462)
Lead Hardware (Embedded board) Development, Lead System Software
Development (UPnP protocol, Drivers, Network, etc…)
• Robert (Young Joon) Cha (yjcha, ID# 99156967)
Lead Analog Module Development, Assist Software Development (UPnP)

B.3 Tasks Description

The members’ responsibilities for specific tasks in the areas of hardware
development, software development, overall integration, and finalization tasks are further
detailed in this section

Table B.1: Hardware Development

Task Description Member(s) Responsible
Design overall Design the architecture of the entire module, taking account Dave, Tae Ho
hardware architecture the embedded board and other necessary components, such
as Ethernet component and analog component.
Design analog Design the portion of the system that interfaces the micro- Dave, Rob
module circuitry controller to the desired device. For demonstration
purposes, the module will stream in simplex mode from the
PC to the module, which requires a Digital-to-Analog
Converter and an amplifier.
Construct analog The analog module will be constructed on a breadboard to Rob
module allow rapid design changes if necessary.

Table B.2: Software Development

Task Description Member(s) Responsible
Implement Linux kernel The embedded software will be written in C and Dave, Rob, Tae Ho
on embedded board compiled using the gcc compiler.
Write analog module Linux drivers will be written to support the Dave, Tae Ho
device drivers digital/analog hardware. They may need to use DMA
techniques to handle the large data rates.
Embedded UPnP setup This consists of all programming necessary for Dave, Tae Ho
and programming implementation of Universal Plug and Play (UPnP)
protocol on the embedded board.
Search algorithms and Design and implement: Dave, Tae Ho
data structures for - A search engine data structure and utility functions to
representing selected manipulate media; utility functions include selection
media and device and de-selection.
- Dynamic queue for storing and releasing of media
and devices.

B-2
Miscellaneous systems Other features such as remote control of PC’s GUI for Tae Ho
programming media selection and device driver and feature auto-
update capability from an internet server. Include
support for different versions of the Windows/Apple
operating systems.
Note: this is an iterative task, intertwined with the
testing and verification task.
PC UPnP setup and UPnP protocol implementation on the PC to enable its Dave, Tae Ho
programming capability to detect, auto-configure, and control any
device connected to it across the Ethernet network and
to act as a media server to the MCS modules on the
network.
Interactive PDA user GUI that would do the management of media stored in Tae Ho
interface design PC and any audio devices connected to the network.
(Optional) GUI will have a search engine that would allow user to
easily search a specific media, and other necessary
functions for the control of devices.

Table B.3: Overall Integration

Task Description Member(s) Responsible
PC network To evaluate this system, we need a prototype that has a Dave, Rob, Tae Ho
diagnostics software media server, a media renderer and a control point. As a
prototype we intend to have a PC server streaming media to
a stereo amplifier that is equipped with our MCS module.
The PC would have a software implementation of the media
server and optionally a control point.
Communications and The module would allow media from a device to be exposed Dave, Rob, Tae Ho
UPnP system testing and transferred over an Ethernet network. The module
would be capable of providing or accepting streaming
media, controlling the device, and providing information
about the device and its media contents or its capability to
render media. These features will be verified.
UI testing and Unit and high-level testing of completed UI components. Dave, Rob, Tae Ho
verification Note: this is an iterative task that will take place several
times throughout development of all code.

Table B.4: Finalization Tasks

Task Description Member(s) Responsible
Documentation Documentation of Customer Requirements, Project Plan, Dave, Rob, Tae Ho
Functional Specification, Verification Plan, Test Plan,
Design Specification, Interim, and Sign-Off Reports.
Testing and Unit and high-level testing of completed network with Dave, Rob, Tae Ho
verification of final, module equipped audio device and PC.
integrated product
Final Packaging Design and document user-level aspects of documentation Dave, Rob, Tae Ho
for the module and the software applications for the PC
server and the PDA control point. Describe module’s
extensibility as well as possible additional features, such as
the integration into a video device or implementation of
wireless Ethernet.

B-3
B.4 Timeline

May June July August

Design Stage
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Documentation
Customer Requirements
Design Plan & Milestones
Function Specifications
Verification and Test Plan
Design Specification
Interim Report
Design Audit / Sign-Off Report
Design Project Abstract

Development
Design Research
Analog Module PCB Fabrication
Analog Module Initial Testing
MPU Board Testing
MPU Board Linux Setup w/UPnP
MPU Board Programming / Interfacing
PC UPnP Server Development
PC Diagnostics Software Development

Testing
Overall System Testing

B.5 Milestones
One key aspect of our design plan is to first design and implement the hardware
portion of the project in order to deal with possible hardware challenges that may occur.
This would give us the opportunity to do more software verification on the actual
hardware and not on a PC environment and allow us to deal with possible hardware
failure. Some of the UPnP software can be developed and tested on the PC without
requiring the embedded board so shipping delays for the mainboard will not delay
software development. Table B.5 summarizes the project milestones.

Table B.5: Project Milestones

Milestone Description Expected Week Completion
of Completion Week
Execute Verification Execute Verification Plan to ensure that design 4 6
Plan concept works, before implementation
Documentation: Remaining Appendices for future reports 4-5 5
Functional Specs, (Interim, Sign-Off, and Final) (Sign-Off – 12)
Verification Plan, Test
Plan, and Design Specs
Interim Report Documentation of current status of MCS network 5 5
module, mid-way through the term.
Develop main Setup of the embedded development board and 6 6
microprocessor implement Ethernet hardware

B-4
embedded board
Design system software Produce a minimal Linux kernel without an 7 9
solution (Linux kernel MMU and compile it to run on the micro-
and drivers) controller. Develop drivers to support the analog
module.
GUI Prototype An implemented GUI resembling the drawn 7 9
design (possibly with minimal functionality)
Complete All Hardware All hardware components are implemented and 9 11
implementation verified, including the analog module
Implement UPnP UPnP is completely implemented and all 10 10
necessary relevant programming is completed
Design LCD user Design an effective user interface on the device 11
interface (optional)
Design PC user interface Design an effective user interface on the PC 11 10
Tested, verified, The final product result. 12 12
properly functioning
MCS network module
Sign-Off Report Design Audit report, explains success/failures of 12 12
MCS network module and confirms if the
prototype is ready for production.

B.6 Design Challenges

• Porting the Linux kernel for our development board

• Synchronization of analog output at an arbitrary sample frequency
• Staying within network bandwidth limitations
• Familiarization and effective use of the UPnP protocol – Still a very new standard
that has not yet gained a lot of popularity, UPnP protocol will be difficult to
implement and verify since there are no other products on the market
• Designing the system in a manner that facilitates easy troubleshooting
• Ease of use – Determining design using this as the biggest motivating guideline,
and incorporating other standard Ethernet protocol. How to determine what will
be easy to use when sharing media through ethernet? How/where will we verify
this to prevent redesign later on? How will they be reworked or refined?
• Meeting Performance Requirements – Designing and implementing MCS network
module such that it runs at the acceptable customer required speed, and it is small
and cheap enough to be easily integrated into customer’s existing products. Also,
will the CPU fast enough to handle high speed media streams and real-time
decoding?
• A large amount of work is required to be completed in a relatively short period of
time. This lends to challenges, applicable to almost all tasks, such as:
- Limiting scope of design to that which is immediately required.

B-5
 - Maximizing efficiency and robustness of design, possibly saving testing
and improving debugging speed, while not requiring unnecessary work.

B.7 Resource Requirements (state all new additions)

Detailed in this section are the known or anticipated requirements for various resources
for MCS network module.

B.7.1 Lab Space

For hardware development, lab space will be required to develop the main board and the
analog board. For software development, code can be developed on our own home
computers. Thus, a basic workbench with power should suffice.

B.7.2 Equipment
The anticipated equipment requirements for the MCS network module are:
• Our self-owned personal computers for development and demonstration.
• An embedded development board with the chosen microprocessor and Ethernet
capability
• E&CE department’s PCB milling machine may be required. Board etching will
be done using our facilities.
• A logic analyzer for verifying that the analog module is communicating properly.
Our intention is to use one of our own personal computers for demonstration of our
project during the symposium. They will meet the expected hardware requirements of
MCS module network.

B.7.3 Software
For development of MCS module network, we require the software, most of which are
open source projects:
• Source code for Linux
• Eagle’s CADSoft program for PCB (E&CE department)
• Microsoft .NET and MSDN Library (development assistance information
database for Windows development). Partially included with Microsoft Visual
Studio, or available online.
• Python and OpenGL for graphical user interface implementation on the PC
• Linux OS running on a PC for code development and testing
• GCC toolchain for compiling Linux source code.

B-6
 • UPnP (Universal Plug and Play) API for Linux

B.7.4 Budget

The E&CE allocated budget for MCS network module is $150. The anticipated spending
costs for MCS network module are:
• Embedded development board: AXIS Developer Board LX??
• Circuit components for the analog portion (buffer, digital-to-analog converter,
amplifier, etc…)
• Research material (specifically, books, internet, open resources)
The majority, if not all, costs pertaining to research material have already been incurred.
Further cost-requirements for MCS network module are not anticipated and the members
of the group will fund unforeseen cost requirements equally.

B-7
 APPENDIX C
Functional Specifications

The MCS Module is an integrated component of a consumer electronic device to

provide the network connectivity along with other network-based functionalities. This
module, consisting of both hardware and software elements will achieve the goal of
delivering a more complete home entertainment solution.

This document outlines the functional specifications of the MCS Module from
three main perspectives: general system overview, hardware and software. These
functional specifications address the customer requirements using a hierarchical view of
the system itself and its main components.

C.1 System Overview

The MCS Module, henceforth referred to as the module is a microprocessor
system intended to be easily incorporated into existing designs for consumer electronic
devices such as CD players or stereos. The module will provide Ethernet connectivity for
remote control and streaming of media between modules using the Ethernet connection.

Figure C.1 - System Overview

The system will provide the following general functionality in Table C.1 with
priority 1 being the highest priority.

C-1
 Table C.1: General Functional Specifications
Item Priority Detail
Ethernet Connectivity 1 The module will provide connectivity to an Ethernet network
Digital/Analog 1 The prototype module must be capable of performing digital
Conversion to analog conversions for stereo audio out (and vice versa).
This functionality must be extensible to both input and
output of audio (and video for future implementation).
Streaming Media 1 The module will negotiate transfers for the streaming of
stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency without
buffer under-run.
Discovery 2 The module will provide the means of discovery when placed
on the network such that a central control point can keep
record of all the modules on the network.
Content/Capability 3 The module, when queried, will provide a list of all the
Information media available on the electronic device and all of the device
capabilities.
Remote Control and 2 The module will be capable of interfacing with the control
Status circuitry of a variety of electronic devices with minimal
additional hardware adapters.
Data Link 3 The module will be capable of receiving data serially from
the electronic device for the capture of media titles and
descriptions.
Remote Control 2 The module will be capable of exposing the interface to the
electronic device through a standard interface for remote
control purposes

C.2 Hardware Functional Specifications

The hardware functional structure is presented in Figure C.2 and is as follows. A
module mainboard serves as the central unit of the design. There is an Ethernet
connection to the network, at least 8 programmable parallel control lines for interfacing
with the electronic device control circuitry and a serial data link for passing strings of
data between the module and the electronic device. An analog module, specific to the
application will be connected to the system bus and will perform the function of D/A or
A/D conversions. The module will be capable of control of itself and other modules
through an LCD and Keypad module that will be connected to the system bus (optional).

C-2
 Figure C.2 – Functional Diagram of the MCS Module

Table C.2 –Module Mainboard Hardware Functional Specifications

Item Priority Detail
Overview The module mainboard will be a single-board computer that
is the central unit of our system. It will provide Ethernet
connectivity, an interface to the electronic device and the
ability to plug in various analog modules to process analog
signals.
Power 1 +5VDC - +9VDC power supplied by electronic device
Microprocessor 2 32bit Microprocessor with MMU
Memory 2 8MB DRAM, 2MB Flash for permanent code
DMA 2 DMA channels for Ethernet and audio module interface
Communications 1 10/100 Ethernet (IEEE 802.3) with RJ-45 connector. RS232
programming interface. 1 spare UART with RS232
interface.
Parallel Port Device 1 Programmable parallel port interface of at least 8-bits to
Interface electronic devices remote control circuitry, configurable to
customer application. For example:
Amplifier: Volume up, Volume down
CD player: Play, Stop, Pause, Jog forward, Jog
reverse, Skip forward, Skip reverse
The prototype will implement the amplifier model
Serial Data Link to 2 Transfer of text data between the module and the electronic
Electronic Device device will be facilitated by a serial link using a UART on
the mainboard. This feature will be used in conjunction with
the parallel control lines.

C-3
 Table C.3 – Analog Module Hardware Functional Specifications
Item Priority Detail
Overview The analog module will be an extension board to the
mainboard. Depending on the customer application, the
analog module could provide audio out, audio in, video out,
etc… The analog module required for the design prototype
will provide analog stereo output.
Communications 1 Communication to microprocessor using a synchronous
serial interface. Will require DMA channel to support high
volume of data
Output 1 Analog output signal suitable for input to audio power
amplifier. Output impedance 500Ohm - 1kOhm. Output
voltage range is +-5VDC.
Response Speed 2 The analog module will provide an output signal at a
frequency of up to 128 kbps
Resolution 2 The analog module will process signals with a resolution of
at least 8 bits per channel (left, right).

C.3 Software Functional Specifications

C.3.1 Universal Plug and Play

The module will use the Universal Plug and Play (UPnP) standard for
communication and control over Ethernet. This standard defines three devices: Media
Server, Media Renderer, and Control Point. The software on the prototype module will
implement the Media Renderer. The module will appear on the network as a standard
UPnP device and so it will be compatible with other modules or with PCs running UPnP
software. For detailed information on the UPnP standard refer to http://www.upnp.org.
As an UPnP compliant device the module will have the following functionalities.

C.3.1.1 Addressing

On power up, the module attempts to acquire an IP address from a DHCP server.
If it receives no response the module will randomly select an IP address and attempt to
validate it by sending out an ARP (Address Resolution Protocol) message. If there is no
reply, the module will keep the address, otherwise a new random address will be selected.

C.3.1.2 Discovery

Once the module has acquired an IP address, it will indicate that it is present to
any control points on the network by a multi-cast discovery message. Modules that
implement the control point standard will maintain a list of active modules on the
network for a set expiration time. After this time, if the control point has not received an
update from the module then it is removed from the list. The control point will also have
the ability to multi-cast discovery messages to which each module replies. This would be
used in the case of a control point being added to the network.

C-4
C.3.1.3 Description

Following the discovery of the modules, the modules will send a description of the
device, its capabilities and all available services. The service description includes a list of
actions with associated parameters and state variables.

C.3.1.4 Control

The control point will be capable of invoking actions on the module as defined in
the service descriptions. It will also be capable of querying for the values of any state
variables in the module.

C.3.1.5 Eventing

The control point will be capable of subscribing to receive state variable updates
from any module on the network. When a state variable changes, the module will send an
event to all control points that have subscribed to it.

C.3.1.6 Presentation

Each module will have a URL that will point to a web page that defines a
graphical user interface for that device.

C.3.2 Module Software

The module will be running an operating system that is designed for a MMU
(memory management unit) environment. Device driver modules for controlling the
analog module will be loadable into the OS kernel. Program modules that implement the
UPnP standard will be installed. The prototype module will be a media renderer so the
program code will support the necessary functionality defined within that standard. Code
that is specific to the customer application will handle the idiosyncrasies of configuring
and operating the parallel and serial control lines to communicate with the chosen
electronic device. The module will support updating of program code using the Ethernet
connection.

C-5
 Figure C.3 - Module Software Functional Overview

Figure C.4 – Processes Running on the MCS Module

C.3.3 GUI Specifications

In order for the module to be an effective addition to a multimedia system, it must

be controlled is convenient manner using a handheld remote control device. This remote
control would have full access to the network and any UPnP device connected. The
remote control would have a graphical user interface that would allow an inexperienced
user to rapidly become proficient at controlling the system.

C-6
 The graphical user interface (GUI) will be communicating directly with a control
point and so will have access to the list of all modules and will be capable of requesting
queries, displaying status and initiating remote control commands including media
streams. The GUI will be designed to operate in a consistent manner regardless of the
nature of the module that is being accessed or the medium on which the GUI is
implemented (PC, LCD/keypad, etc…). The GUI shall contain the following functional
elements (see Table C.4):

Table C.4: GUI Functional Specifications

Item Priority Detail
Device/Media List 1 This is a hierarchical structure that can be browsed by the user.
First a module can be selected from the list of active modules.
Then, if the module is a media server then the media within that
device can be selected. If the module is a media renderer then it
can be selected as a media destination.
Remote Controls 2 Each device should have a control panel associated with it for
remote control. The controls displayed to the user will change
depending on the capabilities of the selected module.
Indicators 2 Each module will have a set of indicators or text to give feedback
on the status of the device.
Search 3 The GUI will provide a search engine for finding media based on
name, artist, etc… The GUI will maintain current media content
records for all modules to ensure search times of less than 2
seconds.
Transactions 3 The GUI will be capable of enumerating all transactions between
modules that are active at the control point. Transactions may be
selected and modified by the user.

The following images in Figure C.5 are the minimum required graphical user
interfaces to ensure the easy control of “control point” devices. These elements should be
present in any implementation of the control point.

Figure C.5: Different screens of graphical user interface

C-7
The following table describes the functionality of each GUI screen (see Table C.5).

Table C.5: GUI Screen Descriptions

Screen Name Functional Description
Start-up Upon switched ON, load the GUI and boot the module
Device Discovery List all devices connected in the network, and allow their selection
Music Selection Selection of any music file stored within all devices in the network
Music Library Show all music files organized and indexed with respect to their ID tag,
and ensure browsing capability
Function/Action List all transaction commands.
Status Display the current status of transaction

C.3.4 PC/PDA Software(optional)

A personal digital assistant (PDA) will act as an UPnP control point for the
prototype system. An interactive GUI will provide a user interface to the control point.
Other PC software will provide network usage information for evaluating bandwidth
usage and other diagnostic statistics.

C-8
 APPENDIX D
Design Specification

Table of Contents

D.1 Introduction.......................................................................................................D-2
D.2 Overall System Architecture Specifications ...................................................D-2
D.3 Hardware Specifications...................................................................................D-3
D.3.1 MCS Module....................................................................................................D-4
D.3.1.1 Microprocessor .............................................................................................D-4
D.3.1.2 Development Board ......................................................................................D-5
D.3.1.3 Analog Board ...............................................................................................D-6
D.3.1.3.1 Digital-Analog Converter ..........................................................................D-7
D.3.1.3.2 Analog-Digital Converter ..........................................................................D-10
D.3.1.3.3 Analog Amplifier Circuit ...........................................................................D-12
D.3.1.3.4 Clock Circuit ..............................................................................................D-13
D.3.1.3.5 Overall Analog Board ................................................................................D-13
D.3.2 Human Interface ..............................................................................................D-16
D.3.3 PC Specifications .............................................................................................D-17
D.4 Software Specification ......................................................................................D-17
D.4.1 Operating System ............................................................................................D-18
D.4.1.1 MCS Module Operating System ..................................................................D-18
D.4.1.2 PC Operating System ...................................................................................D-18
D.4.2. Universal Plug and Play (UPnP SDK)............................................................D-19
D.4.2.1 Module Implementation ...............................................................................D-21
D.4.2.1.1 RenderingControl Specification.................................................................D-23
D.4.2.1.2 ConnectionManager Specification.............................................................D-23
D.4.2.1.3 AVTransport Specification ........................................................................D-24
D.4.2.2 PC Implementation ......................................................................................D-24
D.4.2.2.1 ContentDirectory Specification .................................................................D-24
D.4.2.2.2 ConnectionManager Specification ............................................................D-26
D.4.2.2.3 AVTransport Specification ........................................................................D-27
D.4.2.3 PDA Implementation ....................................................................................D-27
D.4.2.4 UPnP Device Operation ...............................................................................D-27
D.4.2.5 UPnP Control Point Operation......................................................................D-28
D.4.3 Module Software ............................................................................................D-30
D.4.4 PC Media Server Application .......................................................................D-31
D.4.4.1 Media Server Configuration Interface ..........................................................D-31
D.4.4.2 Media Server ................................................................................................D-32
D.4.5 Palm Control Point Application ...................................................................D-31

D-1
D.1 Introduction

The MCS Module, henceforth referred to as the module, is an integrated

component of a consumer electronic device that provides network connectivity to
facilitate media streaming and remote control. This module, consisting of both hardware
and software elements, achieves the goal to deliver a more complete home entertainment
solution by exposing common audio or video devices to a home network.

This document outlines the design specifications of the MCS Module with respect
to three main perspectives: overall system architecture, hardware architecture and
software architecture.

These design specifications address the implementation of the major functions

defined in the functional specifications. For the design of the each major component of
the system, key design aspects are identified in detail and any relevant engineering
analysis and/or theory is explained.

D.2 Overall System Architecture Specifications

The overall system will be designed to provide a consumer electronic device, such
as an audio stereo system, with the capability to stream and play audio files from a
computer in a home network. In addition to this, the device will be capable of being
controlled by a remote control point through the standardized interface that it exposes.
The MCS module will be integrated into consumer devices to provide them with network
capability. To provide the consumer with easy setup and configuration, the overall system
will be based on the Universal Plug and Play (UPnP) standard.

The scope of this design includes:

• MCS module hardware implementation
• MCS module system software
• A media server/manager application running on a Linux PC with X Windows

Both the PC and the module will be UPnP compliant so that they will be
compatible with other UPnP devices that may emerge in the future.

As it is shown in Figure D.1 the system is divided into three major hardware
components, and each of these components requires its own suite of software
implementations.

D-2
 Figure D.1: Layout of overall architecture specification

The PC will store audio files in MP3 format. The MCS module will be capable of
receiving and decoding streaming MP3s and producing the analog audio signal. A user
control point, on the PC or otherwise, will identify the desired files from the PC and
initiate media streams between the PC and the MCS module. Any device that is UPnP-
compliant, including the PC, can accomplish user control. The implementation of the
control point and media server GUI was done using Python to ensure portability to
various graphical environments. The above architecture includes the facilitated control
via a PDA (optional for the 4A term week 12’s design audit, but will be implemented for
4B’s symposium) for increased flexibility.

The module will provide the analog output signal that can be fed to a set of
speakers to demonstrate the MP3 streaming ability. The module is not expected to
provide a complete control interface to a consumer device, but may implement some
simple control features. Possible future improvements could be incorporating wireless
LAN using PCMCIA cards (optional for the 4A term week 12’s design audit, but will be
implemented for 4B’s symposium).

Ultimately, a typical home network will consist of one or two PCs and one or
more consumer devices that are equipped with the MCS modules and all of these devices
will automatically detect each other and configure themselves. Though this design
incorporates audio only, possible extension to the project would provide video
capabilities as well (optional for the 4A term week 12’s design audit, but will be
implemented for 4B’s symposium).

D.3 Hardware Specifications

The hardware specifications encompass the hardware aspects of the MCS module,
the PDA (optional for the 4A term week 12’s design audit, but will be implemented for
4B’s symposium) and the PC server.

D-3
D.3.1 MCS Module

The MCS module is the unit that will be integrated into consumer electronic
devices to provide media streaming and remote control functionality (see Figure D.1.1).

Synchronous
Serial Link

D igital-
M edia C ontrol O utput
Analog OUT
Server Point Pream p
Converter

M edia
Ethernet
Renderer

Analog-
Python Input
D igital IN
GUI Pream p
Converter
AXIS D ev Board

Personal C om puter Analog M odule

Figure D.1.1 Overall System Layout

The hardware components of the MCS module include: the microprocessor, the
development board, and the analog board. The following diagram in Figure D.2
represents the physical layout of the board and indicates the major functional parts of the
hardware

Figure D.2: The functional layout of the board

D-4
D.3.1.1 Microprocessor

The microprocessor (Central Processing Unit in Figure D.2) performance

determines the speed of the streaming and the decoding capabilities. To ensure media
quality, the processor must be fast and robust enough to support all potential tasks
(streaming, decoding, etc…) running concurrently. The microprocessor will be an Axis
ETRAX 100LX. The relevant specifications are listed in Table D.1 below.

Table D.1: MCS Module Microprocessor Specifications

Processor Core 100MHz, 32-bit, 15 general registers
Cache 8Kb instruction/data
MMU 4GB per process, 64-entry on-chip TLB
DMA 10 channel, 64byte FIFO
Ethernet 10/100Mbit Ethernet
Serial I/O 4 Asynchronous, 2 Synchronous
Parallel I/O 16 bits of configurable I/O
USB Host/Device mode operation
Timers 2 programmable 8-bit timers plus a watchdog timer

This specification represents the main design aspect of the processor unit of the
board. In addition, the following table summarizes the processor specifications where
they satisfy the functional specifications (in Table D.1).

Table D.2: Processor Specifications

Feature Description/Specification
Processor Core Operating frequency of 100Mhz will be used to ensure sufficiently fast
transfer of the streaming of audio and any other necessary control transaction.
MMU Necessary storage of Linux and application software
DMA 10 Channels is sufficient for Ethernet and output to audio module
10/100Mbit Ethernet Capability of networking from connectivity through RJ-45 connector
16 bits of configurable I/O 2 Programmable 8-bit parallel ports to interface to electronic devices remote
(Parallel Port) control circuitry, configurable to customer application.

For example:
Amplifier: Volume up, Volume down, Mute, Loudness

The prototype will implement amplifier control.

Serial I/O Transfer of text data between the module and the electronic device will be
facilitated by a serial link using the spare UART on the main board.
This feature will be used in conjunction with the parallel control lines.
Watchdog Timer To ensure reliability without user intervention

D-5
D.3.1.2 Development board

The development board (MCS Module Mainboard in Figure D.1) is the principal
site for the placement of other necessary hardware components mentioned in Table D.1,
with the addition of the analog module. The design prototype will use the Axis Developer
Board LX. One UART will be used as a data communication channel with the host
electronic device. Another UART will be used for terminal I/O during development. A
synchronous serial channel under DMA control will be used to communicate PCM data
to the audio module. When development is complete, the module will communicate to
other devices exclusively through the Ethernet connection.

For further detailed design specification of synchronous serial port, please refer to
the device driver section under software category, presented later in this current appendix.

Table D.3: Memory Map of the Axis ETRAX 100LX

Address Range (hex) Size(Mb) Name Description
00000000-03FFFFFF 64 Cse0 EPROM/flash PROM bank 0 chip select
04000000-07FFFFFF 64 Cse1 EPROM/flash PROM bank 1 chip select
08000000-0BFFFFFF 64 csr0 SRAM bank 0 chip select
0C000000-0FFFFFFF 64 csr1 SRAM bank 1 chip select
10000000-13FFFFFF 64 Csp0 Peripheral chip select 0
14000000-17FFFFFF 64 Csp1 Peripheral chip select 1
18000000-1BFFFFFF 64 Csp2 Peripheral chip select 2
1C000000-1FFFFFFF 64 Csp3 Peripheral chip select 3
20000000-23FFFFFF 64 Csp4 Peripheral chip select 4
24000000-27FFFFFF 64 Csp5 Peripheral chip select 5
28000000-2BFFFFFF 64 Csp6 Peripheral chip select 6
2C000000-2FFFFFFF 64 Csp7 Peripheral chip select 7
30000000-3FFFFFFF 256 - Do not use
40000000-7FFFFFFF 1024 - DRAM interface
80000000-AFFFFFFF 768 - Same as 00000000-2FFFFFFF but uncached
B0000000-B7FFFFFF 128 - Internal registers
B8000000-BFFFFFFF 128 - Internal start up code
C0000000-FFFFFFFF 1024 - Same as 40000000-7FFFFFFF but uncached

The module will be running a Linux 2.4 kernel and services will be located in
Flash memory. A RAMdisk will be set up in the system DRAM to provide a basic ‘ext2
filesystem.’ The filesystem will be stored in Flash when un-mounted. A number of
standard Linux services and applications will also be available mainly to ease
configuration and support for various communications protocols. This particular design
issue will be further dealt in the following “Software Design Section.”

D-6
 The board will be pre-assembled with all necessary components. Therefore, the
main design tasks for the development board will consist of software implementation, as
well as physical integration into the audio device and connectivity to the analog module.

D.3.1.3 Analog board

Separately from the development board, the analog board will provide the analog
output of the streaming audio files. The main function of the board is to provide the
conversion of digital signal to analog signal and to amplify the output signal to
reasonable amplitudes. Since the analog board is the only hardware component of the
entire system, most of the hardware design time will be devoted to this board.

The main component of the analog board is definitely the Digital-to-Analog

Converter (DAC) chip, which takes a digital input signal and converts it to an analog
output signal. A lot of research has been conducted to select the most appropriate DAC
while minimizing system complexity. The DAC component chosen for the MCS module
is Analog Devices™’ AD1866 DAC chip. The analog board also includes an amplifier
circuit at the analog output of the DAC chip, due to the fact that the DAC does not have
an internal amplifier needed to provide a sufficient volume. Other necessary minor
components for the analog module include bypass circuits, external crystal oscillator and
filtering circuits.

Implementing an Analog-to-Digital Converter (ADC) would permit the full-

duplex functionality to the MCS module. Due to the time constraint, full-duplex
functionality to the overall system is not implemented, but the ADC is implemented
physically due to simplicity, allowing full-duplex streaming capability to the analog unit
only. The clocking circuits and filter circuits are not simple; however, they are similar to
the circuits required for the DAC, thereby allowing reuse of the same components. The
ADC chip chosen for the MCS module is Texas Instruments’ PCM1801 16-bit Stereo
ADC chip. This chip is chosen due to its relative ease of implementation and low number
of required external components compared to other audio ADC chips, such as the Analog
Devices version of the ADC.

Both the DAC chip and the ADC chip require clock inputs. The clock signal is
provided by a crystal oscillator operating at 11.2896MHz, which is 16 times the sampling
clock frequency. The required clock signals are provided by a separate clock circuit,
which uses binary counters to divide the frequency of a 11.2896MHz crystal oscillator.

D.3.1.3.1 DAC (Digital-to-Analog Converter)

There are many IC vendors that manufacture Digital-to-Analog Converters, with

many different levels of quantization, sampling rates and modulation schemes. The main
purpose of this design project is to design the architecture of the network, thus producing
‘superb-quality’ sounds is not a major criteria. This allows us to select a DAC that is

D-7
more economic and less complex. The AD1866 chip provides us with near-CD quality
and ease of implementation into our designs with its simple configuration and detailed
supporting documentation.

Sampling Rate

The clock of the analog module will provide a sampling rate of 44.1 kHz to the
DAC chip, which is the sampling rate used in common everyday CD players. The human
ear has a natural audio frequency response range of 20 Hz to 20 kHz, approximately.
According the Nyquist Rate Criterion, an analog signal must be sampled at minimum
double the frequency of the signal in order to retain frequency information. Since a
typical audio application does not reach the extremes of the audible frequency range
often, a sampling rate of 44.1 kHz or approximately 110% of Nyquist sampling rate
should be more than sufficient in retaining signal integrity.

Resolution

The resolution of AD1866 is 16 bits. The number of bits per sample of the digital
signal indicates the number of quantization levels. The more number of quantization
levels, the smaller are the quantization errors. 16 bits of resolution result in 65536
quantization levels, which are enough to produce a very accurate analog waveform
without much quantization noise – caused by excessive quantization errors.

Pinouts

For stereo operation, the AD1866 chip is essentially divided into two channels,
each having the same circuits. The DAC can take-in dual serial inputs and output dual
analog output signals. The AD1866 comes in two different packages; in a plastic DIP
package and in a surface-mount SOIC package. For the prototype stage, a DIP package is
preferred for breadboarding. The pin configuration diagram can be seen in Figure D.3
and the pinout designations for the 16 pins of both package types are described in Table
D.4.

D-8
 Table D.4: Pin Designations
Pin Mnemonic Description
1 VL Digital Power Supply (+5V)
2 LL Left Channel Latch Enable
3 DL Left Channel Data In
4 CLK Clock Input Pin
5 DR Right Channel Data In
6 LR Right Channel Latch Enable
7 DGND Digital Common
8 VBR Right Channel Bias
9 VS Analog Power Supply (+5V)
10 VOR Right Channel Output
11 NRR Right Channel Noise Reduction
12 AGND Analog Common
13 NRL Left Channel Noise Reduction
14 VOL Left Channel Output
15 VS Analog Power Supply (+5V)
16 VBL Left Channel Bias

Figure D.3: DAC Pin Configuration

Timing

Figure D.5 illustrates the general signal requirements for the DAC chip. DL and
DR are the serial data inputs that are clocked into the internal serial registers on the rising
edge of the CLK signal. The falling edges of LL and LR signals cause the last 16 bits that
were clocked into the serial registers to be shifted to the DAC converters of the left and
right channels, respectively.

D-9
 Figure D.5: Original Timing Diagram

Device drivers will be required for the microprocessor, which will govern the
input signals into the DAC chip. These will be discussed in the software section of the
document. One serial line is to be fed from the microprocessor due to the fact that the
decoded MP3 file will have information of two channels interleaved word-by-word. One
latch signal is sent at the sampling frequency (44.1kHz) to both latch pins with one signal
inversed, effectively alternating the data signal to left and right channel. Please refer to
Figure D.6 for modified timing diagram. This implies that 32 data bits are sent during one
frame, which requires the clock signal to be sent at 32 X 44.1kHz, which is 1.41MHz.

Figure D.6: Modified Timing Diagram

D.3.1.3.2 ADC (Analog-to-Digital Converter)

One major advantage of implementing an ADC is being able to test the DAC
circuit without the need of software interface. The output of the ADC can be directly
connected to the data input pin of the DAC, as long as the audio format of the ADC
output matches the required input format of the DAC. Just like the AD1866, the
PCM1801 ADC can provide near-CD quality with ease of implementation.

D-10
Sampling Rate

The clock of the analog module will provide a sampling rate of 44.1 kHz to the
ADC chip, which is the sampling rate used in common everyday CD players. The human
ear has a natural audio frequency response range of 20 Hz to 20 kHz, approximately.
According the Nyquist Rate Criterion, an analog signal must be sampled at minimum
double the frequency of the signal in order to retain frequency information. Since a
typical audio application does not reach the extremes of the audible frequency range
often, a sampling rate of 44.1 kHz should be more than sufficient in retaining signal
integrity.

Resolution

The resolution of PCM1801 is 16 bits. The number of bits per sample of the
digital signal indicates the number of quantization levels. The more number of
quantization levels, the smaller are the quantization errors. 16 bits of resolution result in
65536 quantization levels, which are enough to produce a very accurate analog waveform
without much quantization noise – caused by excessive quantization errors.

Pinouts

For stereo operation, the AD1866 chip is essentially divided into two channels
with each having the same circuits. The DAC can take in dual serial inputs and output
dual analog output signals. The AD1866 comes in two different packages; in a plastic
DIP package and in a surface-mount SOIC package. For the prototype stage, a DIP
package is preferred for breadboarding. The pin configuration diagram can be seen in
Figure D.7 and the pinout designations for the 16 pins of both package types are
described in Table D.5.

D-11
 Table D.5: Pin Designations
Pin Mnemonic Description
1 VINL Input Left Channel Analog
2 VINR Input Right Channel Analog
3 DGND Digital Ground
4 VDD Digital Voltage Supply
5 SCKI System Clock In
6 BCK Bit Clock In
7 LRCK Sampling Clock In
8 DOUT Output Digital Signal
9 BYPAS HPF Bypass Control
10 FMT Format Control (I2S, Left-Just)
11 VCC Analog Voltage Supply
12 FMT Analog Ground
13 VREF2 Reference 2 Decoupling
14 VREF1 Reference 1 Decoupling

Figure D.7: ADC Pin Configuration

Timing

Figure D.8 illustrates the general signal requirements for the DAC chip. Unlike
the AD1866, the output of the digital signal is provided through one output pin and two
channels are interleaved after one another. Each 16-bit sample is outputted at each edge
of the load clock signal, therefore an inverter is not needed similar to AD1866.

Figure D.8: PCM1801 Timing Diagram

D-12
Device drivers will be required by the microprocessor to handle the incoming data bits.
These will be discussed in the software section of the document.

D.3.1.3.3 Analog amplifier circuit

The analog output signals of the DAC unit will first need to be amplified and be
cleaned up to rid of most of the noises within the device and other unknown parasitic
signals. Since the human ear can only hear up to 20kHz, an LPF with that cutoff
frequency can be added at the output. Figure D.9 shows the pinout diagram of LM380,
which is a 2.5W Audio Power Amplifier IC, while Table D.6 shows the pin designations.

Table D.6: Pin Designations

Pin Mnemonic Description
1 BYPASS Coupling Capacitor
2 V+ Non-Inverting Input
3 GND Ground
4 GND Ground
5 GND Ground
6 V- Inverting Input
7 GND Ground
8 VOUT Output
9 NC Null
10 GND Ground
11 GND Ground
12 GND Ground
13 NC Null
14 VS Supply Voltage 10-22V

Figure D.9: Opamp Pin Configuration

For most opamps operating from a single voltage supply, virtual grounds are used
to provide the signal amplification. This is also the case with the LM380 Audio Amp,
which means that biasing capacitors are needed at the input and the output of the amp to
block the DC bias. Figure D.10 shows the schematic diagram of the audio amplifier.

D-13
D.3.1.3.4 Clock Circuit

The crystal providing the 11.2896MHz clock signal is the CM309 Crystal
Oscillator from Citizen Crystals. To divide the clock frequency down to the bit clock
signal and the sampling clock signal, binary counters are used. Two SN74LS193 4-bit
counters are used to generate a divide-by-256 frequency divider for the 44.1kHz clock
signal.

D.3.1.3.5 Overall Analog Board

Figures D.10 and D.11 illustrate the overall schematic diagrams, divided into
DAC, ADC and Clock sections of the Analog Board circuit. The value of the crystal
oscillator is 11.2896 MHz, which is 16X oversampling of the signal. Oversampling
introduces more samples above the Nyquist Rate, which leads to higher accuracy.

D-14
Figure D.10: Schematic Diagram for DAC portion of Analog Board

D-15
Figure D.11: Schematic Diagram of ADC portion and clock circuit of Analog Board

D-16
D.3.2 Human Interface (PDA) – OPTIONAL

For the purpose of simple and convenient control of the module-equipped

consumer electronic device, a Palm PDA is may be used as a control point.

To control the streams of audio files, the user would utilize a PDA to interface
with the MCS module and PC media server. The PDA will be designed to provide a
visual interface to the module functions and the PC functions and provide a method of
invoking functions on each using the UPnP interfaces that they provide. Since
implementation of the PDA is meant to provide a user interface only, the hardware
requirements are minimal. Table D.7 describes the minimum specifications for the
hardware. The Palm PDA model “M105” is readily available by the ECE department for
our use; it meets the minimum requirements outlined in Table D.7.

Table D.7: PDA Minimum Specification

Specification Description
PDA type Palm PDA
OS Palm OS 3.0 or better
Processor 16MHz or faster
Memory 2MB RAM or more
Screen Touch-sensitive LCD screen with 160 X 160 resolution or higher
Connectivity Serial port and serial data cable

For the prototype at week 12 of 4A term, the PDA will not be implemented for
the design audit demonstration, instead a personal computer will be used for all
controlling issues. However, for the 4B term symposium, the serial port will be used for
connectivity and communication between the PDA and the MCS module’s development
board which will simply forward the packets to the network (see Figure D.12) though this
can easily be extended to Ethernet or wireless.

Current Song
Track #
Title
Serial Interface To Development Board

Figure D.12: Diagram of PDA as human interface

D-17
D.3.3 PC Specifications

As shown from Figure D.1, the personal computer (PC) will act as the ‘Media
Server’ and also as a ‘Control Point’ with the capability of controlling the “MCS module-
equipped” device or of being controlled by another device such as the PDA control point
(optional). Since the PC itself is not within the scope of the MCS module design
specification, hardware specifications are given to serve as a recommendation for the use
of a PC within the networked system.

In terms of hardware specification, the PC hardware does not need to be robust in

performance, since the UPnP SDK and network operations do not require fast
performance to produce the necessary functions. However, the GUI and index-
manipulation algorithms may benefit from faster processors since the user would not
have to wait longer periods of time.

The PC connects to the module via Ethernet, which implies that an Ethernet card
is required in the PC configuration. Similarly, a sound card would be necessary to play
audio received by the PC. Table D.8 is a list of specifications for the hardware
configuration of the PC.

Table D.8: Suggested PC Specifications

Specification Description
Type Either desktop or notebook
Processor Intel Pentium 400MHz or faster , or PowerMac
Memory 64 MB of RAM or more
OS Windows XP, MacOS, Linux
Hard Drive 4GB or more
Input Devices Keyboard, 2-button mouse or better
Ethernet Any 10/100 Ethernet card
Video Any size monitor and 2MB of video memory or more
Audio 16-bit sound card

Along with the PC, an Ethernet cable is required to provide connection to a home
network. To connect to an Ethernet hub, a straight-through CAT-5 twisted-pair Ethernet
cable will be used.

D.4. Software Specifications

The software specifications include specifications for: the MCS Module system
and ‘Media Renderer’ software, the PC ‘Media Server’ application and the PDA control
point application (optional). Each device uses a reduced implementation of standard
UPnP devices for performance and specific task-oriented purpose of our prototype. The
devices and the parts that will be implemented are specified in this section. The UPnP
system is described as a whole and the interaction between devices is described. Before
going into the details of the software design, it is important to mention that all software
designs are specified within two main software development standards: Portability and
Extensibility.

D-18
D.4.1 Operating System

D.4.1.1 MCS Module Operating System

For the MCS module, the Linux kernel 2.4.15 or later will be used as an operating
system. In addition to the kernel, the following packages are required as a minimum
configuration (see Table D.9):

Table D.9: Linux Specification

Package Commands Provided
The BASH shell echo, false, pwd, sh, true
GNU textutils Cat
GNU fileutils chgrp, chmod, chown, cp, dd, df, ln, ls, mkdir, mknod, mv, rm, rmdir,
sync
GNU sh-utils date, hostname, stty, su, uname
e2fsprogs fsck, fsck.ext2 (e2fsck), mkfs.ext2 (mke2fs)
Util-linux Dmesg, getty (agetty), kill, login, mount, swapon, umount
Sysvinit init, shutdown, halt and reboot

In addition, a “gcc library”, “telnet server”, and “ftp server” would assist
development. The root filesystem on the RAMdisk will have the following structure:
bin Essential command binaries
boot Static files of the boot loader
dev Device files
proc Kernel and process information virtual filesystem
etc Host-specific system configuration
lib Essential shared libraries and kernel modules
mnt Mount point for mounting a filesystem temporarily
opt Add-on application software packages
sbin Essential system binaries
tmp Temporary files
usr Secondary hierarchy
var Variable data

D.4.1.2 PC Operating System

Our implementation of a PC Media Server and Control Point application was built
using the Intel SDK for UPnP devices. Considering should be given in the development
of the application to maintaining a certain degree of modularity and portability such that
it would be a minimal task to port the application to another operating system.

D-19
D.4.2 Universal Plug and Play (UPnP SDK)

UPnP provides a device independent interface that allows the MCS module to
communicate with a range of devices and servers running on various operating systems.
Simply plugging the device into a network with a computer or any other device with the
UPnP implementation will enable its automatic configuration, which includes addressing,
discovery, and indexing of the device.

In this section, a brief overview of the Universal Plug and Play system is given
followed by implementation details for the specific services on each device. These details
identify the UPnP services that will be implemented on the devices and the state variables
and actions that will be implemented in each UPnP service.

Universal Plug and Play will be implemented using the existing Intel SDK for
UPnP Devices. This SDK provides the basic protocol stack to allow UPnP operations.
The basic implementation of UPnP is common to all devices although each device
requires a different set of UPnP services. The following sections detail the specific
aspects of the UPnP standards that are required to be implemented. Further details of the
UPnP standard including the state variables and actions referred to in this section are
available on the web at www.upnp.org.

The software can be divided into two categories, the UPnP device and the UPnP
control point, the software structure is specified in the following sections

UPnP Device (Media Server and Media Renderer)

Both the Media Server and the Media Renderer inherit from the base class
UpnpDevice. This class encapsulates all interactions with the Linux UPnP SDK. It
provides for storing and finding all services within the device and forwards UPnP Events
to the appropriate services. This allows the Media Server and Media Renderer classes to
be concerned mainly with the implementation of the functionality of the services. Figure
D.13 and Figure D.14 illustrates these relationships.

When an UPnP action is sent to a device, it is redirected to the correct service

within the device and the service specific action code is executed. Because, the
functionality of the services within a device is so tightly coupled to the functionality of
the overall device, a centralized approach was taken whereby, all the code for the device
was located in the MediaServer / MediaRenderer class and callbacks are registered for
each action within each service of the device. Therefore, when a service such as
Connection Manager processes an action, the arguments are extracted from the XML and
stored in the state variables of the service. Then the registered callback is invoked, to
notify the main device of the action. Any code within the device can then check the state
variables of that service, set them as necessary, and when the program execution returns
to the service, the return arguments of the action are taken from the state variables and
the action response is sent back to the UPnP SDK.

D-20
 State Variables
UpnpService Content
Base Class Directory
Actions

State Variables
Upnp SDK
UpnpDevice Media UpnpService Connection
for Linux
Ethernet Base Class Server Base Class Manager
Devices
Actions

State Variables
UpnpService AVTransport
Base Class

Actions

registerCallback()

Action Invoked

Figure D.13: Media Server Class Interactions

State Variables
UpnpService Rendering
Base Class Control
Actions

State Variables
Upnp SDK
UpnpDevice Media UpnpService Connection
for Linux
Ethernet Base Class Renderer Base Class Manager
Devices
Actions

State Variables
UpnpService AVTransport
Base Class

Actions

registerCallback()

Action Invoked

Figure D.14: Media Renderer Class Interactions

D-21
Control Point Software Architecture

The Control Point maintains a dynamic list of UPnP devices that are currently
active on the network. UPnP devices routinely send out advertisements that the control
points examine. If the device is not currently in the list, it is added and the XML
description documents for the device and services within are downloaded using HTTP.
Using these description documents, the control point builds an UPnPDevice object and
adds to it UPnPService objects. This tree structure contains all of the metadata from the
XML description documents and provides a simple means of providing metadata to a
application layer user interface. This tree structure is seen in Figure D.15

Linux SDK for

Upnp Devices

Control Point

Upnp Device ...

Upnp Service ...
Upnp
State
Variable
...
Allowed
Value ...
Upnp Action ...
Argument ...
Figure D.15: Control Point Application and Device Metadata List

D.4.2.1 Module Implementation

The module will implement a UPnP MediaRenderer device. To support the

transfer of media, it will have the following UPnP services: RenderingControl 1.0,
ConnectionManager 1.0, AVTransport 1.0. The implementation will be a daemon,
running as a background process. On startup, the module will go through the following
sequence of steps to acquire an IP address as shown in Figure D.16:

D-22
 Request an IP
address from a
DHCP server

DHCP
Use the assigned
response YES
IP address
received?

NO

Randomly
generate an IP
address and send
an ARP request

YES

ARP response Use this generated

NO
received IP address

Figure D.16: Obtaining an IP address

D.4.2.1.1 RenderingControl Specifications

This section outlines the parts of the RenderingControl standard that will be
implemented in the module. Refer to the UPnP RenderingControl 1.0 standard for details
regarding variables and actions (see Table D.10 and Table D.11).

Table D.10: RenderingControl State Variables

State Variable Name Data Type Allowed Value Eventing
LastChange String Yes
PresetNameList String comma-seperated strings No
Mute boolean No
Volume Ui2 Min = 0 No
Max = electronic device
dependent
Step = 1
Loudness boolean No
A_ARG_TYPE_Channel String No
A_ARG_TYPE_InstanceID Ui4 No
A_ARG_TYPE_PresetName String No

D-23
 Table D.11: RenderingControl Actions
Action Name Arguments Direction Associated Variable
GetMute InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
CurrentMute OUT Mute
SetMute InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
DesiredMute IN Mute
GetVolume InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
CurrentVolume OUT Volume
SetVolume InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
DesiredVolume IN Volume
GetLoudness InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
CurrentLoudness OUT Loudness
SetLoudness InstanceID IN A_ARG_TYPE_InstanceID
Channel IN A_ARG_TYPE_Channel
DesiredLoudness IN Loudness

D.4.2.1.2 ConnectionManager Specifications

This section outlines the parts of the ConnectionManager standard that will be
implemented in the module. Refer to the UPnP ConnectionManager 1.0 standard for
details regarding variables and actions (see Table D.12 and Table D.13).

Table D.12: ConnectionManager State Variables

State Variable Name Data Type Allowed Value Eventing
SourceProtocolInfo string Comma-seperated strings Yes
SinkProtocolInfo string Comma-seperated strings Yes
CurrentConnectionIDs string Comma-seperated ui4 Yes
A_ARG_TYPE_ConnectionStatus String “OK”, No
“ContentFormatMismatch”,
“InsufficientBandwidth”,
A_ARG_TYPE_ConnectionManager String No
A_ARG_TYPE_Direction String “Output”, “Input” No
A_ARG_TYPE_ProtocolInfo String No
A_ARG_TYPE_ConnectionID ui4 No
A_ARG_TYPE_AVTransportID ui4 No
A_ARG_TYPE_RcsID ui4 No

D-24
 Table D.13: ConnectionManager Actions
Action Name Arguments Direction Associated Variable
GetProtocolInfo Source OUT SourceProtocolInfo
Sink OUT SinkProtocolInfo
GetCurrentConnectionIDs ConnectionIDs OUT CurrentConnectionIDs
GetCurrentConnectionInfo ConnectionID IN A_ARG_TYPE_ConnectionID
RcsID OUT A_ARG_TYPE_RcsID
AVTransportID OUT A_ARG_TYPE_AVTransportID
ProtocolInfo OUT A_ARG_TYPE_ProtocolInfo
PeerConnectionManager OUT A_ARG_TYPE_ConnectionManager
PeerConnectionID OUT A_ARG_TYPE_ConnectionID
Direction OUT A_ARG_TYPE_Direction
Status OUT A_ARG_TYPE_ConnectionStatus

D.4.2.1.3 AVTransport Specifications

The AVTransport standard will be implemented as specified in the AVTransport

1.0 standard subject to the specifications listed below. Refer to the UPnP AVTransport
1.0 standard for details regarding variables and actions. The module will support only a
single stream and so will have only a single instance of the AVTransport service
supporting the following transfer protocols for streaming (see Table D.14).

Table D.14: AVTransport Protocols

Media Type Transfer Protocol (AVTransport)

Wave HTTP or RTP/RTSP

MP3 HTTP or RTP/RTSP

D.4.2.2 PC Implementation

The PC will implement an UPnP MediaServer device and an UPnP Control Point. To
support the transfer of media, it will have the following UPnP services: ContentDirectory
1.0, ConnectionManager 1.0, AVTransport 1.0. The purpose of the Control Point
implementation on the PC is to provide a means of monitoring the performance of the
overall system.

D.4.2.2.1 ContentDirectory Specifications

This section outlines the parts of the ContentDirectory standard that will be
implemented on the PC. Refer to the UPnP ContentDirectory 1.0 standard for details
regarding variables and actions (see Table D.15 and Table D.16).

D-25
 Table D.15: ContentDirectory State Variables
State Variable Name Data Type Allowed Value Eventing
A_ARG_TYPE_ObjectID String No
A_ARG_TYPE_Result String No
A_ARG_TYPE_SearchCriteria String No
A_ARG_TYPE_BrowseFlag String “BrowseMetadata”, No
“BrowseDirectChildren”
A_ARG_TYPE_Filter CSV string No
A_ARG_TYPE_SortCriteria CSV string “+”[property name], “- No
“[property name]
A_ARG_TYPE_Index ui4 No
A_ARG_TYPE_Count ui4 No
A_ARG_TYPE_UpdateID ui4 No
SearchCapabilities CSV string No
SortCapabilities CSV string No
SystemUpdateID ui4 Yes

Table D.16: ContentDirectory Actions

Action Name Arguments Direction Associated Variable
GetSearchCapabilities SearchCaps OUT SearchCapabilites
GetSortCapabilities SortCaps OUT SortCapabilities
GetSystemUpdateID Id OUT SystemUpdateID
Browse ObjectID IN A_ARG_TYPE_ObjectID
BrowseFlag IN A_ARG_TYPE_BrowseFlag
Filter IN A_ARG_TYPE_Filter
StartingIndex IN A_ARG_TYPE_Index
RequestedCount IN A_ARG_TYPE_Count
SortCriteria IN A_ARG_TYPE_SortCriteria
Result OUT A_ARG_TYPE_Result
NumberReturned OUT A_ARG_TYPE_Count
TotalMatches OUT A_ARG_TYPE_Count
UpdateID OUT A_ARG_TYPE_UpdateID
Search ObjectID IN A_ARG_TYPE_ObjectID
SearchCriteria IN A_ARG_TYPE_SearchCriteria
Filter IN A_ARG_TYPE_Filter
StartingIndex IN A_ARG_TYPE_Index
RequestedCount IN A_ARG_TYPE_Count
SortCriteria IN A_ARG_TYPE_SortCriteria
Result OUT A_ARG_TYPE_Result
NumberReturned OUT A_ARG_TYPE_Count
TotalMatches OUT A_ARG_TYPE_Count
UpdateID OUT A_ARG_TYPE_UpdateID

D-26
D.4.2.2.2 ConnectionManager Specifications

This section outlines the parts of the ConnectionManager standard that will be
implemented on the PC. Refer to the UPnP ConnectionManager 1.0 standard for details
regarding variables and actions.

Table D.15: ConnectionManager State Variables

State Variable Name Data Type Allowed Value Eventing
SourceProtocolInfo String Comma-seperated strings Yes
SinkProtocolInfo String Comma-seperated strings Yes
CurrentConnectionIDs string Comma-seperated ui4 Yes
A_ARG_TYPE_ConnectionStatus String “OK”, No
“ContentFormatMismatch”,
“InsufficientBandwidth”,
“UnreliableChannel”,
“Unknown”
A_ARG_TYPE_ConnectionManager string No
A_ARG_TYPE_Direction String “Output”, “Input” No
A_ARG_TYPE_ProtocolInfo String No
A_ARG_TYPE_ConnectionID ui4 No
A_ARG_TYPE_AVTransportID ui4 No
A_ARG_TYPE_RcsID ui4 No

Table D.16: ConnectionManager Actions

Action Name Arguments Direction Associated Variable
GetProtocolInfo Source OUT SourceProtocolInfo
Sink OUT SinkProtocolInfo
PrepareForConnection RemoteProtocolInfo IN A_ARG_TYPE_ProtocolInfo
PeerConnectionManager IN A_ARG_TYPE_ConnectionManager
PeerConnectionID IN A_ARG_TYPE_ConnectionID
Direction IN A_ARG_TYPE_Direction
ConnectionID OUT A_ARG_TYPE_ConnectionID
AVTransportID OUT A_ARG_TYPE_AVTransportID
RcsID OUT A_ARG_TYPE_RcsID
ConnectionComplete ConnectionID IN CurrentConnectionIDs
GetCurrentConnectionIDs ConnectionIDs OUT CurrentConnectionIDs
GetCurrentConnectionInfo ConnectionID IN A_ARG_TYPE_ConnectionID
RcsID OUT A_ARG_TYPE_RcsID
AVTransportID OUT A_ARG_TYPE_AVTransportID
ProtocolInfo OUT A_ARG_TYPE_ProtocolInfo
PeerConnectionManager OUT A_ARG_TYPE_ConnectionManager
PeerConnectionID OUT A_ARG_TYPE_ConnectionID
Direction OUT A_ARG_TYPE_Direction
Status OUT A_ARG_TYPE_ConnectionStatus

D-27
D.4.2.2.3 AVTransport Specifications

The AVTransport standard will be implemented as specified in the AVTransport 1.0

standard subject to the specifications listed below (see Table D.17). Refer to the UPnP
AVTransport 1.0 standard for details regarding variables and actions. The PC will
support multiple connections from MediaRenderer devices using the following protocols.

Table D.17: AVTransport Protocols

Media Type Transfer Protocol (AVTransport)
Wave HTTP or RTP/RTSP
MP3 HTTP or RTP/RTSP

D.4.2.3 PDA Implementation – Optional

The PDA will be an implementation of an UPnP control point and will be the
main point of user interaction with the system. The PDA needs code to query the
MediaServer and MediaRenderer and control the media transactions between them.

For the design audit demonstration, the PDA will be left unimplemented due to
time constraint and its classification as low priority; however, it will be implemented and
demonstrated during the 4B term symposium.

D.4.2.4 UPnP Device Operation

This section describes the application software that will be running on the
embedded module. The UPnP application structure for a device is illustrated in Figure
D.17 and Figure D.18 below. When the application starts, it registers the XML
description of the device and a callback function that will be called on incoming
asynchronous messages. The application then multicasts and ssdp:alive advertisement to
indicate its presence to any control points. The current thread will then sleep for a set
time interval to allow threads running the callback function time to process. Upon waking,
the thread will check if the device is shutting down in order to send ssdp:byebye
messenges to control points. If it is not shutting down, the application will check for
changes in the hardware I/O interface to the electronic device. Any relevant changes will
be made to effect the state variables of the device and events will be sent to subscribing
control points. Then the thread will go back to the sleep state and repeat. The callback
function essentially identifies the nature of the incoming message and calls the
appropriate handler.

D-28
 Register Root
Device
Desicription and
Callback

Multicast
Call from SDK on
ssdp:alive separate thread
messages

What is the
EventType?
Sleep to allow
other threads to
handle requests
Subscription Call Subscription
Request Request Handler

Check electronic
Is the device device I/O
NO
shutting down? interface for state
changes
Get Variable Call Get Variable
YES Requests Request Handler

Multicast
Did the state
ssdp:byebye NO
change?
messages

Action Call Action

YES
Requests Request Handler

Update state
variables and do
eventing

Figure D.17 – Main UPnP Program Loop Figure D.18 – Callback Function

D.4.2.5 UPnP Control Point Operation

This section describes the application software that will be running on the PC and
the PDA. The UPnP application structure for a control point is illustrated in Figure D.19
and Figure D.20 below. When the application starts, it registers the XML description of
the control point and a callback function that will be called on incoming asynchronous
messages. The application then sends asynchronous search requests to find any active
devices. The search responses will come via the callback function

D-29
 Call from SDK on
separate thread
Register client
desicription and
callback function
What is the
EventType?

Perform Request
asynchronous ssdp:alive Do we want a description
YES
search to find advertisement description? document from
devices device

Asynchronous
search result

Sleep to allow
Add the device to
other threads to Device Update device
the control point
handle requests Event state table
device registry

Is the device Send actions on Save the returned

NO Action
shutting down? behalf of the user values from the
Complete
action call

YES

Remove the
ssdp:byebye device from the
Unregister Client
advertisement control point
device registry

Figure D.19 – UPnP Main Program Figure D.20- Callback Function

After the control point has discovered an implementation of a MediaServer and

MediaRenderer, it is ready to initiate media transactions. The transactions proceed as
illustrated in the following figure D.21.
The ContentItem is chosen from the ContentDirectory of the MediaServer, and is the
source that is to be rendered. The ContentItem provides information regarding the type of
media as well as the protocols supported by the MediaServer for that type. Here are the
steps for invoking actions for streaming:
1) ConnectionManager::getProtocolInfo() is called on the MediaRenderer
2) Returned protocols are compared with those of the ContentItem
3) If there is no common protocol then the application fails with an error
4) Otherwise, the application will call
ConnectionManager::prepareForConnection() on the MediaServer to get a
unique AVTransportID
5) AVTransport::setAVTransportURI() is called to identify the source URI of
the media
6) AVTransport actions are invoked to control the flow of the streaming media.

D-30
 ContentItem chosen
from MediaServer

Call
Call getProtocolInfo on prepareForConnection
the MediaRenderer on the PC server and
get the AVTransportID

Call
Compare the protocol
SetAVTransportURI to
returned with that of the
define the location of
MediaServer
the media

Invoke actions to
Protocol
control the media
Supported?
stream

Error: The
MediaRenderer does
not support the protocol

Figure D.21 – Control Point Media Transaction

D.4.3 Module Software

The MCS Module application software will be responsible for handling all
aspects of UPnP, streaming and auto-updating over Ethernet. A separate thread as shown
in the following figure will handle each function. The UPnP functions will be handled by
a single thread (not including auxiliary threads created by the SDK code). When a request
to start a media stream is received, the module software will create a thread to handle the
streaming, decoding, and playing of the audio stream. The streaming will be done over a
single TCP connection and will be buffered for at least 1 second. There exists the
possibility of using RTP/RTSP for streaming. This could be easily incorporated into the
code. The decoder/sound processor module will be selected depending on the chosen
encoding scheme. Our implementation will stream wav files and PCM data by default
but can operate with a plug-in codec for mp3 or otherwise. The Linux MAD SDK is
considered to decode the MP3 stream. The MAD SDK can be found at
http://www.underbit.com/products/mad PCM data from the stream or from the decoder
is sent to the synchronous serial port /dev/syncser0 where they are transferred to the

D-31
analog module DAC. A device driver for the synchronous serial port is supplied by
AXIS and can be loaded into the kernel image.

UPnP Process Update Daemon

UPnP Auto-Updating
Control Software

Media Streaming Process

Decoder/ Analog
Streaming
Sound Module
Control
Processor Drivers

Figure D.22: Module Software Execution Threads

D.4.4 PC Media Server Application

This section specifies the Media Server application that will be running on a PC
and will serve streaming MP3 files to a media renderer device on the network. The Media
Server will allow the user to select collections of MP3 files for sharing and will run
unobtrusively as a background process serving UPnP requests from other devices. The
software for the media server application can be divided into the following components:
the configuration interface (or GUI), and the underlying UPnP media server.

D.4.4.1 Configuration Interface

The configuration interface will allow for the user to select media sources on the
PC as well as over an internet connection. This will be facilitated by a class
MediaCollection that will be a collection of references to files, folder, and URLs. The
user will be able to add and remove items from this collection. Figure D.23 shows a
wireframe of the application.

D-32
 Figure D.23 – Media Server Application Wireframe

D.4.4.2 UPnP Media Server

When the configuration interface is not open, the Media Server will be running in
the background and will monitor the network for UPnP traffic. This application contains
an implementation of the UPnP media server device specified in D.4.2.2 PC
Implementation and so will be required to perform the UPnP functions outlined therein.
The MediaCollection will be searched by control point devices to locate available media
on the server.

D.4.5 Palm Control Point Application - Optional

This section specifies the control point application that will be implemented on
the Palm PDA but also on the PC as an additional convenience feature of the control
point application. The breakdown of the control point user interface is into two parts: the
Graphical and Control Commands (non-Graphical) interfaces as shown in the following
figure:

Graphical User Control Commands

Interface Interface

User Interface
Prototype

Integration using
UPnP API

Figure D.24: User Interface Breakdown

D-33
 The graphical user interface (GUI) refers to the controls that the user can see
visually on palm’s screen or PC’s screen. This includes things such as menu items and
device-control commands such as play, stop, etc – all of which invoke some user
command.

The control command (non-graphical) interface, which constitutes the back-end

component of graphical user interface, represents the controls that the user cannot see
visually on-screen, but exist nonetheless. For example, all the commands necessary to
invoke the play command to actually call the song from the storage medium and
coordinating to the targeted device, and then play the media according to other
specification, if there are any, from a simply button press or key press command from
viewable GUI.
The menu commands available to the user are listed in Table D.18.

Table D.18: MCS Module Control Commands.

Menu Command Resulting Action
List List all devices in the network
Device
Select Select the device where you want to coordinate your commands
Playlist (Album) List all user-created playlist of songs
Artist Index all songs according to alphabetical order Artist’s name
Song Library
Genre Index all songs according to song’s genre
Song List all available songs in alphabetical order
Play Play the selected song or songs (if it is playlist)
Pause Pause the Song (idle)
Action
Stop Stop the current song
Commands
Next/Prev Skip to the next song or the previous song
Repeat Repeatedly play the current song
Extra Feature Info Displays device status and any network traffic info

The GUI of these commands will be implemented with Python as designed in the
following figure to ensure user-friendliness and easy-to-use aspect.

D-34
 Figure D.25: Different GUI screens

However, these GUIs will be merged into one control panel for the design prototype
demonstration in week 12.

The non-graphical user interface can be viewed as somewhat of a state machine.

That is, the user will change from different states of operation, depending on the actions
taken on the environment (i.e. which combination of mouse and keyboard buttons that are
pressed). Still, the final goal of this interface is to achieve the intended operation
described in the high-end graphical interface (see Table D.19).

Table D.19: GUI Screen Commands

Screen Name Functional Description
Start-up Upon switched ON, load the GUI and boot the module
Device Discovery List all devices connected in the network, and allow their selection
Music Selection Selection of any music file stored within all devices in the network
Music Library Show all music files organized and indexed with respect to their ID tag,
and ensure browsing capability
Function/Action List all transaction commands.
Status Display the current status of transaction

In terms of Control Commands interface design, the main design specifications

will be divided into three sub-sections: Selecting/Deselecting Device,
Selecting/Deselecting Songs, and Operations on Songs.

Similarly, the selection and de-selection of songs follow in similar manner as

demonstrated in the following state diagram.

D-35
 GUI Selecting/
Command
Deselecting
Songs
Check: Check:
Deselection MCS Module selection
(control point)

Disconnect If the command Connect

is sent to PC
(control point)

Song deselected PC Song selected

Figure D.27: State Diagram of selecting/deselecting songs

Finally, another back-end user interface implementation will consist of operation

commands on songs (see Table D.20 for different playback functionalities). In this case,
the operational command will be uni-directional to the “song media,” actually stored in
the MCS module’s memory from the graphical user interface.

SONG
(in module’s memory)

PLAY STOP BROWSING

(special features)

Figure D.28 Flow chart of Operational commands on Songs

Here, the software implementation is little more complex due to the necessary
control of the analog module in order to play the actual song.

D-36
 APPENDIX E
Verification Plan

The following document outlines the detailed plan for verifying the design of the
MCS Module prior any prototyping.

The customer requirements are first addressed in terms of the functional

components of the module and their specifications. Various verification methods are
mentioned throughout the document that will enable us to ensure that our functional
specifications will meet the customer requirements.

Then, several analysis techniques and design verification plan were conducted to
confirm that design specification will fulfill the customer requirements as well. Design
concepts in relation to specific functional specification are examined in a modular
“block-to-block” manner for each of the software and the hardware designs. The methods
of linking each component of block diagrams in a cyclic manner will then finalize the
complete satisfaction of customer requirements, thus reducing any potential deficiencies
that might result from inefficiencies of one component or overlooked optimization.

Subsequently, the structural design abstraction is optimized among all possible

design alternatives, thus successfully assessing all the customer requirements.

E.1 Verification of Customer Requirements

In relation to functional specification

In order to ensure that all our functional and design specifications will meet the
customer requirements, the main customer requirements are first re-stated with their
descriptions in the context of the functional specification. In doing so, the functional
specification of three main components (PC, MCS Network Module, Consumer device)
has been divided into several specific functional components as it is indicated in the
legend of figure E.1. It is with respect to these functional categories that the customer
requirements will be specified. In this matter, the functionalities and their capabilities will
be managed in the form of block flow diagram with each functional component
accomplishing the actual customer requirements. Figure E.1 is a functional block
diagram which gives an overview of each specific functional area (in letter code) and
how they pertain to the hardware and the software. Table E.1 relates each of these areas
to an aspect of the customer requirements by a customer requirement ID (CID) which
corresponds to each numbered point in the customer requirements document.

E-1
 PC MCS Module Consumer
Device

H
B E C

D F

A G J
I

A: Hardware: Axis C: Hardware: Analog E: Hardware: PDA G: Software: GUI of I: Software: UPnP on
board module (Optional) MCS module PC
B: Hardware: Ethernet D: Hardware: PC F: Hardware: H: Software: GUI of J: Software: UPnP on
module Consumer device PC Module
(Optional)
Figure E.1: Block diagram of functional components

Table E.1: Summary of Customer requirements w.r.t. functional components

Functional Component CID Customer Requirements
1 Network connectivity to a consumer device and computer via
A, B, D, F Ethernet module.
2 Duplex streaming of audio (or video media [optional]) stored on a
A, B, C, D, F hard disk of a computer or on any media storage (CD, DVD) of
other module equipped devices.
3 Modules must be capable of controlling devices in order to
A, E, G coordinate the media streaming.
4 Implementation of the UPnP interfacing protocol to allow the
A, D, F, I, J automatic detection of any new devices on the network and to
provide all necessary information about the new devices.
5 Implement a user-friendly interface on PCs or module equipped
devices that indexes the available media files on the network and
allow fast and easy browsing of the files. The module will provide
G, H detailed information regarding the media content of the device in
such a way that the contents can be indexed and browsed by a user.
It will provide detailed information regarding the type and format of
media that the electronic device is capable of rendering.
6 The module must be economically feasible both in terms of cost and
A, B, C, E time/labour for a manufacturer to integrate it into their existing
products.
7 The module must have a minimal form factor to fit in existing
A, B, C electronics enclosures without necessitating any additional
mechanical changes.
8 The module shall provide a standard interface to the device such
that consumer electronics manufacturers can easily integrate the
A, B, C module with the existing electronic controls, and allow remote
operation and serial communication.

E-2
 9 The software must be modular so that functionality can be added as
needed as per the specific application. An auto-update facility must
A, B, C, G, H be provided that supports automatic software updates making the
module transparent to the user.
10 The module shall also be extensible and capable of supporting
additional custom features beyond the standard interface through
A, C, I, G spare configurable I/O lines. The module must be easily extensible
to support video media.

11 Adaptable to control of other consumer electronic devices such as

A, B, I, J microwaves leading to home automation solutions.

CID = Customer Requirement ID

In relation to Design specification

The design specification (as indicated in Appendix D) has been divided into
several design components: ‘Hardware-Embedded Board’, ‘Hardware-Analog Module’,
‘Software-User Interface’, and ‘Software-UPnP.’ These design units will be observed and
analyzed to verify the satisfaction of all customer requirements. Our design specifications
will meet the customer requirements, which are now stated in the context of the different
design units. In this matter, the design components will be managed in the form of block
flow diagram with each block accomplishing the actual customer requirements, thus
emphasizing its necessity and essentiality. Figure E.2 is a functional block diagram which
gives an overview of each specific design unit (in letter code). Table E.2 relates each of
these areas to an aspect of the customer requirements by a customer requirement ID
(CID) which corresponds to each numbered point in the customer requirements document.

Hardware Software

C G I

A
B

F
H J
B D

A: Hardware: Axis C: Hardware: Analog E: Hardware: Control G: Software: GUI of I: Software: UPnP of
board module Points Control Points Control Points
B: Hardware: Ethernet D: Hardware: Media F: Hardware: Remote H: Software: GUI of J: Software: UPnP of
module - Streaming Server Control Points (optional) Media Server Media Server
Figure E.2: Block diagram of design components

Table E.2: Summary of Customer requirements w.r.t Design Units

E-3
 Design Unit(s) CID Customer Requirements
1 Network connectivity to a consumer device and computer via
A, B, D, E Ethernet module.
2 Duplex streaming of audio (or video media [optional]) stored on a
A, B, C, D, E, F, H hard disk of a computer or on any media storage (CD, DVD) of
other module equipped devices.
3 Modules must be capable of controlling devices in order to
A, E, F, G coordinate the media streaming.
4 Implementation of the UPnP interfacing protocol to allow the
A, D, F, I, J automatic detection of any new devices on the network and to
provide all necessary information about the new devices.
5 Implement a user-friendly interface on PCs or module equipped
devices that indexes the available media files on the network and
allow fast and easy browsing of the files. The module will provide
G, H detailed information regarding the media content of the device in
such a way that the contents can be indexed and browsed by a user.
It will provide detailed information regarding the type and format of
media that the electronic device is capable of rendering.
6 The module must be economically feasible both in terms of cost and
A, B, C, E time/labour for a manufacturer to integrate it into their existing
products.
7 The module must have a minimal form factor to fit in existing
A, B, C electronics enclosures without necessitating any additional
mechanical changes.
8 The module shall provide a standard interface to the device such
that consumer electronics manufacturers can easily integrate the
A, B, C module with the existing electronic controls, and allow remote
operation and serial communication.
9 The software must be modular so that functionality can be added as
needed as per the specific application. An auto-update facility must
A, B, C, G, H, I, J be provided that supports automatic software updates making the
module transparent to the user.
10 The module shall also be extensible and capable of supporting
additional custom features beyond the standard interface through
A, C, D, I, G spare configurable I/O lines. The module must be easily extensible
to support video media.

11 Adaptable to control of other consumer electronic devices such as

A, B, I, J microwaves leading to home automation solutions.

CID = Customer Requirement ID

E.2 Verification of Functional Specification

For the purpose of identifying unnecessary components, each of these customer
requirements is translated into the corresponding functional blocks (see Figure E.1). With
the above-stated comparison to customer requirements (see Table E.1), the necessity and
essentiality of each functional unit is verified.

In Table E.3, the functional specifications are compared to the customer requirements.

E-4
 Table E.3: Summary of functional specifications
Functional Customer Detail
Specifications Requirements ID
Ethernet 1 The module will provide connectivity to an Ethernet
Connectivity network
Digital/Analog 2, 3 The prototype module must be capable of performing
Conversion digital to analog conversions for stereo audio out. This
functionality must be extensible to both input and output
of audio and video.
Streaming Media 2, 3 The module will negotiate transfers for the streaming of
stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency
without buffer under-run.
Discovery 4 The module will provide the means of discovery when
placed on the network such that a central control point
can keep record of all the modules on the network.
Content/Capability 5 The module, when queried, will provide a list of all the
Information media available on the electronic device and all of the
device capabilities.
Remote Control 3 The module will be capable of interfacing with the
(optional) control circuitry of a variety of electronic devices with
minimal additional hardware adapters.
and Status
Data Link 5 The module will be capable of receiving data serially
from the electronic device for the capture of media titles
and descriptions.

The comparison along with the functional block diagram is a method of validating
any plausible assumptions made in the functional specification. With the aid of the block
diagram, in which each unit is detailed with functional and customer requirements, each
analysis can proceed in a block-to-block manner, so identification of erroneous
assumptions or unnecessary functional units can be done within a particular block,
without affecting any of other components.

From the above summaries, the functional specifications match very closely to the
customer requirements. With the use of a functional block diagram, the relationship
between each functional component, with its respective functionalities, and the customer
requirements are managed in a structural manner so that any design oversights or invalid
design assumptions can be identified and constrained to the corresponding functional
blocks (see Table E.3). In this analysis technique, all functional specifications can be
proven in terms of their necessity and plausibility before any design duty begins.

Clearly, when the functional specifications listed in Table E.3 are established, the
customer requirements in Table E.1 are consequently achieved as well.

It is important to note that the establishment of customer requirements regarding

the size and cost of the device can be simply verified through the layout of the device’s
functional components and the cost associated with it. In this case, the verification tool is

E-5
the layout of the module with its functional components, which will verify the feasibility
of the containment of all components within the expected module size. In terms of the
cost requirement, if the cost of the individual components plus an estimated
manufacturing cost are below the customer requirement then we have satisfied the cost
requirement for mass-production.

E.3 Verification of Design Specification

For the purpose of identifying unnecessary components, each of these customer
requirements is translated into the corresponding design units (see Figure E.2). With the
above-stated comparison to customer requirements (see Table E.2), the necessity and
essentiality of each design unit is verified.

In Table E.4, the design specifications are compared to the customer requirements.

Table E.4: Summary of design specifications

Design Customer Detail
Specifications Requirements ID
Hardware – All, except 5 Control Points constitute the main component of MCS
Embedded Network module incorporating most of the features.
Although it doesn’t directly support, its interconnectivity
Motherboard with other components makes it an essential unit
(Control Points)
Hardware – 1, 2, 6, 7, 8, 9, 11 For any streaming via Ethernet, or possible wireless if
Ethernet Module time allows, Ethernet module is the main design unit
responsible for all possible networked features
(streaming)
Hardware – 2, 7, 8, 9, 10 For the particular usage in audio/video consumer
Analog Module electronic devices, this module allows all possible
conversion to make the system functioning
Hardware – Media 1, 2, 4, 10 Meant to keep enable home network entertainment, this
Server unit consists of intelligent media handling capability

Software – UPnP 4, 9, 10, 11 Universal Plug And Play is the core issue of the design,
(Control Points as well supporting any of customer requirements
necessitating any of its features, directly or indirectly
and Media Server)
Software – GUI 2, 3, 5, 9, 10 This design issue satisfies the customer requirements of
(Control Points user-friendly interface, easy, simplicity, and interactive
experience to users
and Media Server)

The comparison along with the design block diagram is a method of validating
any plausible assumptions made in the design specification. With the aid of the block
diagram, in which each unit is detailed with design and customer requirements, each
analysis can proceed in a block-to-block manner, so identification of erroneous
assumptions or unnecessary functional units can be done within a particular block,
without affecting any of other components.

E-6
 From the above summaries, the design specifications match very closely to the
customer requirements. With the use of a design block diagram, the relationship between
each design component, with its respective design specification, and the customer
requirements are managed in a structural manner so that any design oversights or invalid
design assumptions can be identified and constrained to the corresponding functional
blocks (see Table E.4). In this analysis technique, all design specifications can be proven
in terms of their necessity and plausibility before any design duty begins.

Clearly, when the design specifications listed in Table E.4 are established, the
customer requirements in Table E.2 are consequently achieved as well.

It is important to note that the establishment of customer requirements regarding

the size and cost of the device can be simply verified through the layout of the device’s
physical design components and the cost associated with it. In this case, the verification
tool is the layout of the module with its design parts, which will verify the feasibility of
the containment of all components within the expected module size. In terms of the cost
requirement, if the cost of the individual components plus an estimated manufacturing
cost are below the customer requirement then we have satisfied the cost requirement for
mass-production.

The subsequent comparisons of functional specification and design specification

with customer requirements have checked any possible dependency between them, thus
further validating the optimized specifications in function of customer requirements.

E.4 Tools and Concepts

Besides using the block diagram to verify the functional and design specification
designs, other software tools such as a hardware emulator or specific test-oriented scripts,
as well as known concepts and facts will be used for software and hardware design
validation.

The main programming tools that will be used Linux kernel for embedded board
programming, GCC, G++ for any ANSI C or C++ programming and Python for graphical
user interface programming. This set of tools should accomplish all expected
programming tasks. The UPnP software for the embedded module can be written and
fully tested on a PC running Linux prior to being uploaded to the embedded board.

The UPnP implementation, the file searching and streaming, and the UPnP’s
discovery algorithms remain unspecified; thus, they will be proven by verifying that they
have been verified elsewhere – i.e. that the UPnP’s discovery algorithm is already issued
the title of “standard” and no other modification is required, but rather, can be simply
employed.
Ensuring these tools can be used to accomplish the goals of MCS network module
will take the form of verification that they have been used, not necessarily in conjunction

E-7
with one another, to accomplish goals similar to those of MCS network module in the
hardware/software industry.

In terms of hardware, the only component that requires hardware development is

the analog module. Verification of hardware design can be accomplished by analyzing
the datasheet associated with the DAC and other necessary components. Before
prototyping, verification of individual hardware components of the system can be done
individually. Also, the analog module can have predetermined test points which, during
verification, will provide a list of test outputs that can be used in prototype testing.

In terms of AXIS Board-related design issues, the fact that this developer board is
pre-assembled with necessary software components, the board itself with its
specifications represents the verified data, thus eliminating the needs to set up a plan to
verify it.

The potential of MCS network module’s successful integration into the existing
audio device, the hardware specification of several popular audio systems will be
analyzed, thus ensuring the feasibility of a possible easy integration.

Finally, the module’s improvement factor on home automation and home network
system will be confirmed from the new innovative feature added by the module over the
existing products.

E.4 Performance Verification

The performance measurement of the MCS module is measured in terms of 6
different categories as specified in the Table E.3.

Table E.5: Performance specifications of customer requirements

Requirements Performance Specifications
Ethernet capability Standard 10 Mbps connection; must provide a standard RJ-45
connector for Cat 5 Ethernet cables.
Audio streaming Decode audio compressed audio and convert to analog with a
quality that exceeds 128 kbps stereo. Sounds should be free of
any human perceptible distortions.
UPnP UPnP SDK allows the device to automatically detect other
Implementation devices on the network and auto-configures itself to permit
integration into the existing media network.
User interface An intuitive interface that indexes media from all capable devices
connected to the network, and allows the user to browse through
the media and control them via the user interface.
Cost The cost of the module should be no more than $80.00 CDN. It is
acceptable if the prototype exceeds this limit provided the system

E-8
 meets these cost requirements in a mass-production situation

Size The overall size of the module should be no larger than the size of
a standard PCI card.

Within these performance requirements, the speed and the reliability of the
operation are examined to attain the minimum performance level. Unfortunately, any
meaningful verification of the requirement of hardware performance is not possible
without implementation. While the minimum capabilities of the hardware can be verified
by the identification of functional specifications for every component used to achieve the
targeted goal, the final verification of performance and subsequent data will be available
only after the final implementation.

Our verification of the performance will be incremental, and will proceed as

implementation progresses. When possible we will measure the speed performance of
each component and obtain an estimate of the final performance, when the module with
other home network devices such as audio and PC and all software are in the home
network (see Appendix G and H). For the speed requirements of the network, a
mathematical formulaic approach can be taken to verify that our design will meet the
required performance specifications outlined in the customer requirements.

The verification of the user-friendliness of the graphical user interface will be

done in a comprehensive manner of determining the ease of use simply from several
screenshots of GUI. The GUI design will be evaluated with respect to a GUI standard
criterion, and will be projected towards a final performance result by its closeness to the
standard. As implementation continues, revisions may be made to the original GUI
design to represent all necessary functionality. It is from such measurements that we can
verify the ease-of-use requirements will be sufficient for the GUI defined in the Customer
Requirements.

E-9
 APPENDIX F
Test Plan for Constructed Design Prototype

This appendix section discusses the procedures that will be taken to test the MCS
Module to determine whether the performance specifications of the constructed design
prototype meet those that are outlined in the Functional Specifications.

The project is composed of both hardware and software elements; both of which,
in turn, are comprised of smaller functional components. Similar to the verification plan,
the test plan is divided into functional components, which results in a modular testing
procedure. As each component is prototyped, the test plan will be executed afterwards to
ensure that the individual component is functional before integration with the rest of the
system. Also, tests for the overall system and performance tests are addressed in this
document.

F.1 Hardware Testing

For the various hardware components of the module, most of the testing needs to
be done once the entire system have been configured properly. It is intended that an
embedded development board will be used, which means that most of the hardware
components are pre-built and need to be simply integrated with the rest of the
components. The analog module, which makes up the signal conversion portion of the
system, will also require full system integration before most of the testing can be
conducted since it is dependent on serial communication from the microprocessor.

Table F.1 lists the hardware functional components and describes planned tests for the
respective components.

Table F.1: Hardware Functional Components and Testing Descriptions

Functional Component Testing Description
Embedded Board Since the micro-controller is going to be supplied with a
development board, the embedded built-in debugger can be
used to test this component. An external PC setup is needed
to debug the embedded board separately.
Analog Module This board will be comprised of signal converters (DAC,
ADC) and all the complementary components that are needed
for these converters. As described in the verification plan, the
analog module can be designed with test points. These test
points can be probed before and after this component is
integrated with the rest of the system to determine the voltage
levels at specific points on the circuit.

F-1
F.2 Software Testing
Due to complexity of the software components and the variety of platforms involved,
rigorous tests need to be conducted to assure that the module will function properly under
many different test cases.

Table F.2 lists the software functional components and describes planned tests for the
respective components.

Table F.2: Software Functional Components and Testing Descriptions

Functional Component Testing Description
UPnP Implementation The UPnP testing will be broken down into independent
testing of: addressing, discovery, description, control,
eventing and presentation, in that order.
PDA GUI (Optional) The PDA GUI will be tested to ensure that correct status
information is displayed and fits within the PDA display
boundaries
PC GUI The GUI will be tested for expected functionality (ie menu
items lead to correct screens and button perform as expected)

F.3 System Testing

Majority of the testing will be done after the entire module is prototyped and assembled.
The tests outlined in Table F.3 will be conducted once all components have been
individually tested and the overall system has been composed.

Table F.3: Overall System Testing Descriptions

Functional Component Description
Overall UPnP Testing of the entire UPnP system and media streaming using
Implementation robust test cases. A bandwidth measurement will be taken to
determine how many devices can simultaneously be
operating on the network.
Electronic Device The interface to the electronic device will be thoroughly
Connectivity tested using a sample electronic device or test probes.

F.4 Performance Testing

As was outline in the Customer Requirements, the module must meet specific
performance specifications requirements in order to qualify the module as a successful
project. Note that cost and size performance specifications are not taken into
consideration during testing, since these specifications do not apply to a prototype as they
are already fully satisfied by the design verification.

F-2
 Table F.4: Performance Testing Descriptions
Performance Specifications Testing Description
Ethernet capability Performance of the Ethernet capability will be tested by
streaming multiple audio signals to ensure that multiple
streaming within a network can be handled by the overall
system.
Audio streaming Software tools can be used to validate the streaming
digital stereo audio quality of 128kps, but testing analog
audio quality will be a subjective procedure. To consider
noise implications at the output of the analog module, we
will prepare a pilot tone in MP3 format and will test the
analog output signal using various testing tools.
UPnP Implementation The performance of the UPnP will be tested by verifying
that all possible actions are invoked on the module.
User interface The UI for both the PC and the module interface will be
tested to ensure ease of use and error-free.

F-3
 APPENDIX G
Paper Design Verification Data

With ‘Verification Plan,’ as structured in Appendix E, our design specification was

verified to meet all the necessary functional and customer requirements before any
prototype implementation. Thus, the design verification data, both qualitative and
quantitative, were gathered to ensure the feasibility of the design.

First, the design specification is modeled into an abstract prototype, in modular

fashion, in order to generate design verification data. This modular method of verification
plan, as shown in Appendix E, is conducted with respect to the functional specifications.
Particularly, the functional specifications are verified against specific expected design
implementations. Similarly, the customer specifications are analysed and justified with the
aid of detailed design issues.

Secondly, specific existing tools and concepts, intended to verify our design
implementation choices, are used to generate sufficient validation data of our design plan.
These tools and concepts are equally evaluated for different design alternatives with respect
to our design criterions as a means of a quality assurance of our design.

Finally, with respect to these two different verification data, one based on the
abstract design modelling plan and the other one generated by more concrete, proved
analysis methods, the design specification is finalized with the indication of successful
prototyping.

G.1 Verification Data from Modular Verification Plan

Once the design is completed, the design needs to undergo a series of verification
tests in order to minimize the number of design flaws and mishaps. It is during this phase
that major design changes may take place to make sure that the design will meet the
requirements outlined in the Customer Requirements and the Functional Specifications
section while maintaining feasibility of the project. Using the results from verifications, the
group must ensure that no major changes are necessary once the prototype stage has been
reached.

In order to verity the functional specifications of the design, specific design

specifications are planned and optimized to fully attain all functional specification (see
Table G.1).

Table G.1: Verification of Design Specification w.r.t Functional Specifications

Functional Design Implementation Detail
Specifications Specification
Ethernet Axis Embedded The module will provide connectivity to an Ethernet
Connectivity Board (Ethernet network
 Module) + UPnP
Digital/Analog Analog Module The prototype module must be capable of performing
Conversion (DAC, ADC) digital to analog conversions for stereo audio out. This
functionality must be extensible to both input and output
of audio and video.
Streaming Media RTP/RTSP The module will negotiate transfers for the streaming of
protocol stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency
without buffer under-run.
Discovery UPnP SDK The module will provide the means of discovery when
(Control Points) placed on the network such that a central control point
can keep record of all the modules on the network.
Content/Capability UPnP SDK The module, when queried, will provide a list of all the
Information (Media Server) media available on the electronic device and all of the
device capabilities.
Remote Control UPnP SDK The module will be capable of interfacing with the
and Status (Control Points) control circuitry of a variety of electronic devices with
minimal additional hardware adapters.
Data Link Linux Device The module will be capable of receiving data serially
Driver + Axis’ from the electronic device for the capture of media titles
and descriptions.
Synchronous Serial
Port + Media
Server

The functional components, which can be described as Control Points, Media

Server, Media Renderer, Media Streaming, Analog Board, User Interface, are detailed in
terms of specific expected design implementations (see Table G.2). Such method of
subscribing specific design methodologies for every functional component enhances the
assurance of a complete design plan.

Table G.2: Verification of Expected Design Implementation w.r.t Functional Components

Functional Planned Design Implementation Detail
Components Implementation
Control Points Axis Embedded The module will provide connectivity to an Ethernet
Board (Ethernet network.
The module will provide the means of discovery when
Module) + UPnP placed on the network such that a central control point
SDK (ControlPoint can keep record of all the modules on the network
+AVTransport
protocol)
Media Server UPnP MediaServer The module, when queried, will provide a list of all the
Library media available on the electronic device and all of the
device capabilities.
Media Renderer UPnP The module will negotiate transfers for the streaming of
MediaRenderer stereo audio.
Library
Media Streaming UPnP . The module will negotiate transfers for the streaming of
(AVTransport) stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency
+ RTP/RTSP
 protocol without buffer under-run.

Analog Board Analog Module The prototype module must be capable of performing
(DAC, ADC) digital to analog conversions for stereo audio out. This
functionality must be extensible to both input and output
of audio and video.
User Interface Python , This design issue satisfies the customer requirements of
C++ Callback, user-friendly interface, easy, simplicity, and interactive
experience to users
UPnP Commands
Remote Control Python , The module will be capable of interfacing with the
Points (Optional) C++ Callback, control circuitry of a variety of electronic devices with
minimal additional hardware adapters.
UPnP Commands

Finally, the abstract design model in the form of functional specifiation’s

verification data is evaluated against the customer requirements (see Table G.3). Thus,
these abstract design models, in function of various criterions, have generated the design
verification data.

Table G.3 Verification of Expected Design Implementation w.r.t Customer Requirements

Customer Requirements Planned Design Implementation
Specification
Network connectivity to a consumer device and computer via Axis Embedded Board (Ethernet
Ethernet module. Module) + UPnP SDK (ControlPoint
+AVTransport protocol)
Duplex streaming of audio (or video media [optional]) stored UPnP (AVTransport)
on a hard disk of a computer or on any media storage (CD, + RTP/RTSP protocol
DVD) of other module equipped devices.
Modules must be capable of controlling devices in order to UPnP MediaServer Library
coordinate the media streaming. UPnP MediaRenderer Library

Implementation of the UPnP interfacing protocol to allow the UPnP SDK (ControlPoint
automatic detection of any new devices on the network and to +AVTransport protocol)
provide all necessary information about the new devices.
Implement a user-friendly interface on PCs or module equipped Python ,
devices that indexes the available media files on the network C++ Callback,
and allow fast and easy browsing of the files. The module will
provide detailed information regarding the media content of the
UPnP Commands,
device in such a way that the contents can be indexed and UPnP MediaServer
browsed by a user. It will provide detailed information Library
regarding the type and format of media that the electronic
device is capable of rendering.
The module must be economically feasible both in terms of Axis Embedded Board (Ethernet
cost and time/labour for a manufacturer to integrate it into their
Module)
existing products.
Analog Module
(DAC, ADC)
The module must have a minimal form factor to fit in existing Axis Embedded Board (Ethernet
electronics enclosures without necessitating any additional Module)
mechanical changes.
The module shall provide a standard interface to the device Axis Embedded Board (Ethernet
such that consumer electronics manufacturers can easily Module) + UPnP SDK (ControlPoint
integrate the module with the existing electronic controls, and
allow remote operation and serial communication.
+AVTransport protocol)
The software must be modular so that functionality can be UPnP SDK
added as needed as per the specific application. An auto-update Python
facility must be provided that supports automatic software
updates making the module transparent to the user.
The module shall also be extensible and capable of supporting UPnP SDK
additional custom features beyond the standard interface Python
through spare configurable I/O lines. The module must be
easily extensible to support video media.
Adaptable to control of other consumer electronic devices such UPnP SDK
as microwaves leading to home automation solutions.

As it can be seen from the above relation of the three tables, the designed
implementation model complies both functional and customer requirements, indicating the
validation of design specification.

G.2 Tools and Concepts Verification Data

Each individual tool and collection of concepts cited in the Verification Plan has
been examined to determine whether their use and/or employ in MCS Network Module will
be feasible.

Besides using the block diagram to verify the functional specification designs, other
software tools such as a hardware emulator will be used for software and hardware design
validation. For the actual programming tasks, there are many programming tools that are
available for our use, such as G++ for Linux platform and Python for graphical user
interface programming. This set of tools should accomplish all expected programming
tasks.

For the UPnP implementation, the file searching and streaming, and the UPnP’s
discovery algorithms remain unspecified; thus, they will be proven by verifying that they
have been verified elsewhere – i.e. that the UPnP’s discovery algorithm is already issued
the title of “standard” and no other modification is required, but rather, can simply be
employed.

In terms of hardware, since Embedded Developer Board (Axis) is pre-assembled,

the only component that requires hardware development is the analog module. Verification
of hardware design can be accomplished by analyzing the datasheet associated with the
DAC and other necessary components. Before prototyping, verification of individual
hardware components of the system can be done individually.

Most of the hardware components have been predetermined in the datasheets by

proven component values. Our responsibility is to verify that those components are
compatible with others on the analog module. Verification data section at the end of this
document outlines various verification measures taken in confirming the paper design.
 The MCS module is designed to use open source software where possible. Due to
the nature of open source communities, a lot of verification can be obtained from the
internet via internet communities and open source websites. Though there is no product on
the market that is the same as the MCS module, due to the increasing popularity of UPnP,
many UPnP enthusiast websites can be used as verification tools.

G.2.1 Software

UPnP SDK

UPnP is an open standard that is being contributed to be a number of market leaders

such as Intel and Microsoft such as those selling operating systems and network hardware,
support UPnP by packaging an implementation of the UPnP standard with their products.
These implementations take the form of software libraries, as well as drivers, and any
special UPnP features capable of optimizing both the hardware and the software. This
nature of Upnp can guarantee it’s reliablility as a protocol for interdevice operations.

In terms of our design specification, UPnP SDK is the most efficient tool that can
support our main functional components (see Appendix D): ‘Control Points’, ‘Media
Server’, ‘Media Renderer’, ‘Media Streaming.’

The Intel SDK for Upnp Devices encapsulates all of the basic Upnp functionality.
It handles all required network protocols, discovery protocols and contains an XML library
for parsing of messages and description documents. It provides an API that allows devices
and control points to communicate using actions and events. This SDK has been verified
by Intel and so can be taken as a reliable library for building on to. The software that
utilizes this SDK can be separated into control point software and device software.

Control Point Software

To be a properly functioning control point, the software must maintain a list of

active devices on the network, convey metadata for the devices, subscribe to and receive
event notifications for devices and invoke actions on devices. This software can be written
in C or C++ for portability and debugged using GNU debugger to ensure proper operation.

Device Software (Media Server and Media Renderer)

Device software implements a number of services, each with state variables and
actions. The software must call actions coming from control points and send notifications
to subscribed control points when evented state variables change. This software is also
well suited for writing in C++ and can be verified using GNU debugger.
 The services that are implemented on each device are standardized UPnP services
designed to facilitate sending multimedia information across a network. This
standardization ensures that the system will work as expected and be compatible with other
devices using the same standard.

Media Streaming
In the simplest case streaming can be accomplished using a socket stream and TCP
between two points. For improved performance, protocols designed for reliable real-time
multimedia streaming such as RTP/RTSP are available in open source libraries. These
could be used if simpler methods do not produce the desired results.

Extensibility
The model for the Upnp device facilitates easy extensibility by utilizing services in
a modular fashion. If additional services are required, this allows them to plug easily into
the existing code for increased functionality.

Portability
Since a significant portion of code is being written for an embedded environment,
portablility is a large concern. Software libraries will be restricted to using the standard
GLIBC. This will allow us to port the device software to most if not all embedded Linux
systems. An implementation of UPnP is also packaged with the Microsoft Windows
operating system.

An implementation of UPnP is packaged with the Microsoft Windows operating system.

Python

In order to meet several functional and customer requirements for user-interface, the
programming language Python is chosen for the user interface implementation in the design
specification. The versatility of Python’s functionalities can simply be categorized as a
form of our verification data for the following issues in Table G.1.

Table G.1: Python and Functional Specifications

Functional Specifications Python’s Features
Extensibility, Portability Extension with C++ (SWIG)
Low Assembly Command System software (Embedded)
Simple code Easy and complete library
Faster than any other GUI programming for Performance (Fast with C++)
C/C++ callback

Linux

Using an embedded Linux system offers several advantages. Code is easier to

develop since it can be tested on the host Linux platform before being cross-compiled. The
open source nature of Linux makes debugging of system problems such as driver operation
possible by examining the source code. Also, many open source libraries are available for
Linux that can be compiled to an embedded target.

G.2.2 Model / Simulation Used

The embedded system software implementation is not possible without the physical
hardware that the software will be programmed into. However, the selection of various
software tools and implementation concepts can be regarded as a partial verification data
for the project. We have verified that the chosen tools for the embedded board will perform
our required functions.

Before further deciding their particular use in our project, we implemented simple
test scripts to test the efficiency and any other particular characteristics of the above
software selections.

Simulating UPnP

The optional features of Universal Plug and Play that will be required have been
identified and an application specific version of the UPnP device standards has been
developed. The features that we have chosen to implement correspond to those in the
functional specifications. Therefore, given that UPnP performs properly we have verified
that these functional requirements have been fulfilled.

G.2.3 Hardware

Embedded MicroProcessor

The requirements for a typical Hardware device (on which control points will run)
can be verified to be sufficient by meeting our performance requirements, specified as part
of required functionality, and to industry standards. There exists, in the consumer electronic
industry, many embedded systems of greater complexity which run sufficiently at the
hardware requirements specified by MCS Network Module. This makes selection of the
embedded board easier. The Axis ETRAX 100LX board satisfies all requirements by
providing Ethernet, synchronous serial for digital audio, and sufficient speed to handle
decoding and system operation. So, the hardware requirements placed on the embedded
board can be verified to be acceptable.

G.2.4 Algorithms
In terms of final software verification, it is very abstract to verify the software. In
this regards, the team has agreed upon that well documented algorithms that have proven to
perform the task are going to be used and that save time would represent our means of
software verification. Also, the optimization of these algorithms for high performance is
also a source of software verification, although there is no actual output.

G.2.5 Existing MCS Network Module-like products

The fact that the hardware components’ design for “MCS network module” requires
parts from many different vendors demands time to get them delivered to us. For example,
the main board “Axis ETRAX LX” has not arrived from Sweden. In addition, the design
specification has undergone several modifications and revisions from various discoveries of
new hardware and of new implementation methods.

Our group had originally decided to use the Coldfire micro-controller due to its
availability. However, our verification of processor speed indicated that the 33MHz clock
speed of the development was too slow for decoding of MP3 real-time. We have
considered using external hardware MP3 decoder as a means to compensate for the slow
processing power. We have decided to pursue an alternative microprocessor solution. We
chose to go with the Axis ETRAX solution because of the fast 100MHz processing speed
and the fact that it also had an MMU, which allows multi-threading capabilities.

The hardware design progress is not sufficient enough to provide any form of
verification data, except the hardware design and analysis done on paperwork. Since any
hardware verification requires specific hardware, the hardware verification is not yet
applicable at this stage of the project.

G.3 Performance Verification Data

It is difficult to verify the performance requirements for a number of reasons.
Performance is a function of multiple functional blocks, which implies that is difficult to
verify individual components of the system to verify performance. Also, the main function
of the module is the UPnP implementation and the user interface, which can only be
measured qualitatively once the prototype is built.

Unfortunately, any meaningful verification of the requirement of hardware

performance is not possible without implementation. While the minimum capabilities of the
hardware can be verified by the identification of functional specifications for every
component used to achieve the targeted goal, the final verification of performance and
subsequent data will be available only after the final implementation.

Many of the performance parameters can be verified by benchmarking against the

industry standards. The 44.1kHz sampling rate has been verified by theoretically by
Nyquist rate. Which governs that the lowest sampling rate required to retain the frequency
information is to double the frequency of the audio signal. The industry standard for
sampling frequency is set to be 44.1kHz for most CD players, which leads us to verify our
own paper design.
 Although audio quality is not one of the major requirements of the project, it is
important to ensure that signal integrity is kept to allow enjoyable listening during
demonstration or even testing. To retain good quality of the audio signal, resolution of 16
bits was chosen and this is proven to produce decent quality in audio signal, since most PC
sound cards have 16 bits of resolution. This ensures that our project out design goals are
met by having performance requirements that are similar to those products in the
hardware/software industry, as was outline in the verification plan.

Our verification of the performance will be incremental, and will proceed as

implementation progresses. When possible we will measure the speed performance of each
component and obtain an estimate of the final performance, when the module with other
home network devices such as audio and PC and all software are in the home network. For
the speed requirements of the network, a mathematical formulaic approach can be taken to
verify that our design will meet the required performance specifications outlined in the
customer requirements.

The verification of the user-friendliness of the graphical user interface will be done
in a comprehensive manner of determining the ease of use simply from several screenshots
of GUI. The GUI design will be evaluated with respect to a GUI standard criterion, and
will be projected towards a final performance result by its closeness to the standard. As
implementation continues, revisions may be made to the original GUI design to represent
all necessary functionality. It is from such measurements that we can verify the ease-of-use
requirements will be sufficient for the GUI defined in the Customer Requirements.

It is impossible to perform any kind of performance benchmarking without the

actual hardware and software parts. Therefore, any meaningful verification data regarding
performance level is unavailable.

However, several revisions of hardware and software design specifications with

respect to expected functionalities performed during the design stage serve as a method to
theoretically review the performance. Similar to other cases, there will be visible output as
a verification data from the fact that it is only the beginning of development stage, and that
any hardware assembly is not completed yet. For instance, the hardware design
modification from the use of micro-controller to the use of micro-processor to allow a
sufficient increase in streaming performance indirectly represents a way of reviewing the
performance level, thus qualifying the design change as a performance verification data.
 APPENDIX H
Prototype Test / Measurement Data

This document discusses the output of the procedures (see Appendix F) that were
be taken to test the MCS Module to determine whether the performance specifications of
the constructed design prototype meet those that are outlined in the Functional
Specifications.

The project is composed of both hardware and software elements; both of which,
in turn, are comprised of smaller functional components. Due to the complexity of the
overall system, a detailed test plan is performed to ensure that all components of the
system are functional according to the functional specifications and that they meet the
customer requirements.

Similar to the verification plan and data, the test plan is divided into functional
components, which results in a modular testing procedure, and modular
test/measurement data. As each component is prototyped separately, the test plan was
executed afterwards to ensure that the individual component is functional before
integration with the rest of the system. Indeed, as integration was labelled as lower
priority for design prototype, the test/measurement plan will be conducted in a modular
fashion for each component to generate performance data validating the success in
prototyping the design. Indeed, tests’ results for the overall system and its performance
tests will be addressed in the final report, as well as during the symposium with more
advanced features.

F.1 Hardware Testing

For the various hardware components of the module, most of the testing needs to
be done once the entire system have been configured properly. It is intended that an
embedded development board will be used, which means that most of the hardware
components are pre-built and need to be simply integrated with the rest of the
components.

F.1.1 Axis Tests

After the completion of individual part’s testing, the mal-functioning of the serial
port was found via various testing. Indeed….timing signal was passed, and also the
frequency of the signal was controlled by the control points on PC, however at the
analog module, we only observed the timing signal and frequency variations, and not the
data. So upon verifying device drivers, which is approved by Linux Open Source
committee( inidicating that there was no error), we discovered that the dma wouldn’t set
up properfly with the synchronous serial port…which have been the problem…as a
result..the problem was found to be the defective serial port….)….
H.1.2 Analog Module

Equipment Used:
Agilent 54672D Mixed Signal Oscilloscope
Lambda 20V Power Supply
Agilent 33120A 15MHz Function Generator
Mastercraft Digital Multimeter

Before the entire board was prototyped, the amplifier circuit was built and tested.
The original design included a regular 741 operational amplifier, supplied by a single 5V
supply. The design appeared flawless on paper, but many problems arose during testing
after a prototype was built.
Figure H.x shows that the output of the original design with a gain of 2 and no
load. The problem was the low impedance of the system, which caused major
distortions even at low amplitudes.

Figure H.1: Output of original opamp design

Upon replacing the input resistor and the feedback resistors to higher values, the
output appeared much more distortion-free. Figure H.x and H.x shows the output of the
opamp at 200Hz and 20kHz, respectively. The output amplitudes were low and not very
loud without the signal getting distorted.
 Figure H.2: Output of 741 opamp at 200Hz

Figure H.3: Output of 741 opamp at 20kHz

Once the earphones/speakers were loaded onto the output of the opamp, the
output was severely distorted, which is due to rail-voltage limitations caused by low
supply voltages. This was then we have discovered that 5V was below the minimum
input voltage ranges.
 Figure H.4: Output of 741 opamp with 16ohm load (earphones)

Although a higher power supply voltage was used, the distortion was too severe
for a virtual ground that was set at 2.5V. A completely new design approach was taken
by using audio power amplifiers that were available on hand. The replacement amplifier,
LM380, proved to be very beneficial, since it produced a much louder volume without
distortion. Figure H.x shows the output of a music signal, the amplitude of which easily
exceeded 1Vpp.

Figure H.5: Output of LM380 with speaker load

 Once the entire analog module was prototyped, few clocking issues were needed
to be cleared. The Analog-to-Digital Converter chip was also implemented to test a full
loop by inputting analog signal to ADC end, connecting the output to the input of the
DAC and outputting an analog signal. Figure H.x shows the data bits exchanged
between the ADC and the DAC. It is easy to see that the sampling clock was triggering
the two channels accordingly.

Figure H.6: Data bits from the ADC sent to the DAC

Figure H.x illustrates the ability of the analog board to reproduce the analog
signal admirably. Figure H.x is the output of the analog board when a 1 kHz sine wave
was inputted. As can be seen from the figure, the signal is fairly distorted due to the
A/D and D/A stages. Upon listening tests, the distortion can barely be heard at 1 kHz,
which in turn allows us to conclude that the analog module produces sufficient audio
quality to for the MCS module.
 Figure H.7: Comparison of input and output music signal of analog module

Figure H.8: Comparison of input and output 1kHz sine wave of analog module

The analog module, which makes up the signal conversion portion of the system,
will also require full system integration before most of the testing can be conducted
since it is dependent on serial communication from the microprocessor.
Table F.1 lists the hardware functional components and describes planned tests for the
respective components.

Table F.1: Hardware Functional Components and Testing Descriptions

Functional Component Testing Description
Embedded Board Since the microprocessor is going to be supplied with a
development board, the embedded built-in debugger can be
used to test this component. An external PC setup is needed
to debug the embedded board separately.
Analog Module This board will be comprised of signal converters (DAC,
ADC) and all the complementary components that are needed
for these converters. As described in the verification plan, the
analog module can be designed with test points. These test
points can be probed before and after this component is
integrated with the rest of the system to determine the voltage
levels at specific points on the circuit.

Due to complexity of the software components and the variety of platforms involved,
rigorous tests need to be conducted to assure that the module will function properly
under many different test cases.

Table F.2 lists the software functional components and describes planned tests for the
respective components.

Table F.2: Software Functional Components and Testing Descriptions

Functional Component Testing Description
UPnP Implementation The UPnP testing will be broken down into independent
testing of: addressing, discovery, description, control,
eventing and presentation, in that order.
PDA GUI The PDA GUI will be tested to ensure that correct status
(not implemented) information is displayed and fits within the PDA display
boundaries
PC GUI The GUI will be tested for expected functionality (ie menu
items lead to correct screens and button perform as expected)

F.2.1 UPnP Implementation Testing

Program Output for Upnp Infrastructure Testing

The following program output is for the situation of 1 Control Point, 1 Media
Server and 1 Media Renderer. All 3 programs are executing simultaneously and
communicating over the network interface. The purpose of this test is to ensure that
each module behaves as expected and to validate the Control Point device metadata
based on the XML description documents. It can be seen in the following output
captures that each module does in fact behave as expected and device metadata does in
fact match the corresponding description document. Each of the three following
sections contains a brief explanation of the meaning of program output lines.

Media Server Execution

When the Media Server starts up, the services within are constructed and added
to the service table of the device. The state variables are set to their default values. The
setting of state variables normally generates events to send to the control point. This
explains the large number of notify event statements. When the device has finished
setting up the services, the service table is printed. The three services added are now
displayed. The Upnp SDK is initialized on the first network interface with a random
port and starts a web server. The XML description document is passed to the SDK
which allows it to send out advertisements. At this point, the device simply waits for
instructions from a control point.
Creating services...
Add service called with ContentDirectory urn:schemas-upnp-org:service:ContentDirectory1:
Add service called with ConnectionManager urn:schemas-upnp-
org:service:ConnectionManager1:
Sending notify event for ConnectionManager
Sending notify event for ConnectionManager
Add service called with AVTransport urn:schemas-upnp-org:service:AVTransport1:
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransportDone

The service table is:

0. ServiceId: ContentDirectory
ServiceType: urn:schemas-upnp-org:service:ContentDirectory1
1. ServiceId: ConnectionManager
ServiceType: urn:schemas-upnp-org:service:ConnectionManager1
2. ServiceId: AVTransport
ServiceType: urn:schemas-upnp-org:service:AVTransport1
Initializing UPnP Sdk with
ipaddress = (null) port = 0
UPnP Initialized
ipaddress= 192.168.2.140 port = 49154
Specifying the webserver root directory -- ./web
Registering the RootDevice
with desc_doc_url: http://192.168.2.140:49154/MediaServer1.xml
RootDevice Registered
UDN is: uuid:123456789-s
Advertisements Sent
Subscription Accepted
Subscription Accepted
Subscription Accepted
Action Received..
Shutting down Upnp services...

Media Renderer Execution

 The Media Renderer execution is essentially identical to that of the Media Server
with the exception of a different service being loaded. Media Server and Media
Renderer are both derived from the same base class that incorporates the main
functionality of a Upnp device.
Add service called with RenderingControl urn:schemas-upnp-org:service:RenderingControl1:
Add service called with ConnectionManager urn:schemas-upnp-
org:service:ConnectionManager1:
Add service called with AVTransport urn:schemas-upnp-org:service:AVTransport1:
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransport
Sending notify event for AVTransportDone

The service table is:

0. ServiceId: RenderingControl
ServiceType: urn:schemas-upnp-org:service:RenderingControl1
1. ServiceId: ConnectionManager
ServiceType: urn:schemas-upnp-org:service:ConnectionManager1
2. ServiceId: AVTransport
ServiceType: urn:schemas-upnp-org:service:AVTransport1
Initializing UPnP Sdk with
ipaddress = (null) port = 0
UPnP Initialized
ipaddress= 192.168.2.140 port = 49155
Specifying the webserver root directory -- ./web
Registering the RootDevice
with desc_doc_url: http://192.168.2.140:49155/MediaRenderer1.xml
RootDevice Registered
UDN is: uuid:123456789-r
Advertisements Sent
Subscription Accepted
Subscription Accepted
Subscription Accepted
Action Received..
Shutting down Upnp services...

Control Point Execution

The control point begins by initializing the Upnp SDK using the first network
interface and a random port. The control point then begins receiving ssdp:alive
messages from Upnp devices on the network. When these messages are received, if the
device does not already exist in the control points device table, the XML device
description document is retrieved and parsed. The information within this document
allows the control point to subscribe to services within the device and build local
metadata object for describing the device. The subscription is identified by SID and
informs the Upnp device to send events to the control point whenever evented state
variables in the service change. Once the device description document is parsed, the
control point attempts to download a description document for each service within the
device. When the remote Upnp device accepts a subscription it sends events for all
evented variables. This can be seen in the Received Event statements and the XML
fragments that follow.

When both the devices have been detected, an interaction by the user causes the
device table to be displayed. Clearly, it contains an entry for the Media Server and for
the Media Renderer. User interaction then causes the Upnp action GetProtocolInfo to be
sent. The generated XML node is shown and the response from the remote device and
the XML returned is shown immediately following. Then the last user interaction causes
the metadata of 2nd device in the table to be printed. This metatdata matches the device
and service XML description documents as it should. The control point is then
terminated.
Intializing UPnP with ipaddress=(null) port=0
UPnP Initialized (192.168.2.140:-16383)
Registering Control Point
Control Point Registered

Received device description:

handleNewDevice: Parsing device description document
Subscribing to EventURL http://192.168.2.140:49154/upnp/event/AVTransport...
Subscribed to EventURL with SID=uuid:cf17b8e8-1dd1-11b2-ad13-8b16b0872f05
Subscribing to EventURL http://192.168.2.140:49154/upnp/event/ContentDirectory...
Subscribed to EventURL with SID=uuid:cf17ecd2-1dd1-11b2-ad13-8b16b0872f05
Subscribing to EventURL http://192.168.2.140:49154/upnp/event/ConnectionManager...
Subscribed to EventURL with SID=uuid:cf180e7e-1dd1-11b2-ad13-8b16b0872f05
downloadServiceDescriptions: Downloading and parsing device description document
Successfully downloaded SCPD http://192.168.2.140:49154/AVTransport1.xml
Successfully downloaded SCPD http://192.168.2.140:49154/ContentDirectory1.xml
Successfully downloaded SCPD http://192.168.2.140:49154/ConnectionManager1.xml

Received Event for uuid:cf17b8e8-1dd1-11b2-ad13-8b16b0872f05:

Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<LastChange></LastChange>
</e:property>
</e:propertyset>

Received Event for uuid:cf17ecd2-1dd1-11b2-ad13-8b16b0872f05:

Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<SearchCapabilities>NONE</SearchCapabilities>
</e:property>
<e:property>
<SortCapabilities>NONE</SortCapabilities>
</e:property>
<e:property>
<SystemUpdateID>0</SystemUpdateID>
</e:property>
</e:propertyset>
Received Event for uuid:cf180e7e-1dd1-11b2-ad13-8b16b0872f05:
Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<SourceProtocolInfo>rtsp-rtp-udp:*:PCM:*</SourceProtocolInfo>
</e:property>
<e:property>
<SinkProtocolInfo></SinkProtocolInfo>
</e:property>
<e:property>
<CurrentConnectionIDs></CurrentConnectionIDs>
</e:property>
</e:propertyset>

Received device description:

handleNewDevice: Parsing device description document
Error generating presentationURL from (null) + (null)
Subscribing to EventURL http://192.168.2.140:49155/upnp/event/RenderingControl...
Subscribed to EventURL with SID=uuid:d4e776dc-1dd1-11b2-ad13-8b16b0872f05
Subscribing to EventURL http://192.168.2.140:49155/upnp/event/ConnectionManager...
Subscribed to EventURL with SID=uuid:d4e7a422-1dd1-11b2-ad13-8b16b0872f05
Subscribing to EventURL http://192.168.2.140:49155/upnp/event/AVTransport...
Subscribed to EventURL with SID=uuid:d4e7c542-1dd1-11b2-ad13-8b16b0872f05
downloadServiceDescriptions: Downloading and parsing device description document
Successfully downloaded SCPD http://192.168.2.140:49155/RenderingControl1.xml
Successfully downloaded SCPD http://192.168.2.140:49155/ConnectionManager1.xml
Successfully downloaded SCPD http://192.168.2.140:49155/AVTransport1.xml

Received Event for uuid:d4e776dc-1dd1-11b2-ad13-8b16b0872f05:

Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<LastChange></LastChange>
</e:property>
</e:propertyset>
Received Event for uuid:d4e7a422-1dd1-11b2-ad13-8b16b0872f05:
Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<SourceProtocolInfo></SourceProtocolInfo>
</e:property>
<e:property>
<SinkProtocolInfo></SinkProtocolInfo>
</e:property>
<e:property>
<CurrentConnectionIDs></CurrentConnectionIDs>
</e:property>
</e:propertyset>

Received Event for uuid:d4e7c542-1dd1-11b2-ad13-8b16b0872f05:

Changed Variables was :
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<LastChange></LastChange>
</e:property>
</e:propertyset>

2 devices in control point table

Device 0: UDN = uuid:123456789-s

Device 1: UDN = uuid:123456789-r

Sending Action
ACTION MESSAGE
name: GetProtocolInfo
controlURL: http://192.168.2.140:49154/upnp/control/ConnectionManager
serviceType: urn:schemas-upnp-org:service:ConnectionManager:1
UDN: (null)
serviceId: (null)
Sending node:
<u:GetProtocolInfo xmlns:u="urn:schemas-upnp-
org:service:ConnectionManager:1"></u:GetProtocolInfo>

Action Response Received:

ACTION MESSAGE
name: GetProtocolInfo
controlURL: http://192.168.2.140:49154/upnp/control/ConnectionManager
serviceType: urn:schemas-upnp-org:service:ConnectionManager:1
UDN: (null)
serviceId: (null)
ARGUMENTS
Name: Source
Value: rtsp-rtp-udp:*:PCM:*
Returned document was:
<u:GetProtocolInfoResponse xmlns:u="urn:schemas-upnp-org:service:ConnectionManager1">
<Source>rtsp-rtp-udp:*:PCM:*</Source>
<Sink></Sink>
</u:GetProtocolInfoResponse>
DEVICE
specVersion: (null)
baseURL: (null)
deviceType: urn:schemas-upnp-org:device:MediaRenderer:1
friendlyName: MCS Module Media Renderer
manufacturer: Fourth Year Design Group
manufacturerURL: www.uwaterloo.ca
modelDescription: A destination for streaming media at the MCS module
modelName: MCSRenderer
modelNumber: 1.0
modelURL: (null)
serialNumber: (null)
UDN: uuid:123456789-r
UPC: (null)
SERVICE LIST
SERVICE
serviceId: RenderingControl
specVersion: (null)
serviceType: urn:schemas-upnp-org:service:RenderingControl:1
serviceId: RenderingControl
SCPDURL: http://192.168.2.140:49155/RenderingControl1.xml
controlURL: http://192.168.2.140:49155/upnp/control/RenderingControl
eventSubURL: http://192.168.2.140:49155/upnp/event/RenderingControl
eventSID: uuid:d4e776dc-1dd1-11b2-ad13-8b16b0872f05
ACTION LIST
ACTION
name: ListPresets
ARGUMENTLIST
ARGUMENT
name: InstanceID
direction: in
retval: (null)
relatedStateVariable: A_ARG_TYPE_InstanceID
ARGUMENT
name: CurrentPresetNameList
direction: out
retval: (null)
relatedStateVariable: PresetNameList

<---SECTION REMOVED FOR BREVITY--->

STATE VARIABLE LIST

name: Volume
dataType: ui2
defaultValue: (null)
currentValue: (null)
STATE VARIABLE

SERVICE
serviceId: ConnectionManager
specVersion: (null)
serviceType: urn:schemas-upnp-org:service:ConnectionManager:1
serviceId: ConnectionManager
SCPDURL: http://192.168.2.140:49155/ConnectionManager1.xml
controlURL: http://192.168.2.140:49155/upnp/control/ConnectionManager
eventSubURL: http://192.168.2.140:49155/upnp/event/ConnectionManager
eventSID: uuid:d4e7a422-1dd1-11b2-ad13-8b16b0872f05
ACTION LIST
ACTION
name: GetProtocolInfo
ARGUMENTLIST
ARGUMENT
name: Source
direction: out
retval: (null)
relatedStateVariable: SourceProtocolInfo
ARGUMENT
name: Sink
direction: out
retval: (null)
relatedStateVariable: SinkProtocolInfo

<---SECTION REMOVED FOR BREVITY--->

STATE VARIABLE LIST

STATE VARIABLE
name: SourceProtocolInfo
dataType: string
defaultValue: (null)
currentValue: (null)

<---SECTION REMOVED FOR BREVITY--->

SERVICE
serviceId: AVTransport
specVersion: (null)
serviceType: urn:schemas-upnp-org:service:AVTransport:1
serviceId: AVTransport
SCPDURL: http://192.168.2.140:49155/AVTransport1.xml
controlURL: http://192.168.2.140:49155/upnp/control/AVTransport
eventSubURL: http://192.168.2.140:49155/upnp/event/AVTransport
eventSID: uuid:d4e7c542-1dd1-11b2-ad13-8b16b0872f05
presentationURL: (null)

<---SECTION REMOVED FOR BREVITY--->

F.3 System Testing

Majority of the testing are done after the entire module is prototyped and assembled.
The tests outlined in Table F.3 were conducted once all components have been
individually tested and the overall system has been composed.

Table F.3: Overall System Testing Descriptions

Functional Component Description
Overall UPnP Testing of the entire UPnP system and media streaming using
Implementation robust test cases. A bandwidth measurement was taken to
determine how many devices can simultaneously be
operating on the network.
Electronic Device The interface to the electronic device was thoroughly tested
Connectivity using a sample electronic device or test probes.

H.4 Performance Testing

As was outline in the Customer Requirements, the module must meet specific
performance specifications requirements in order to qualify the module as a successful
project. Note that cost and size performance specifications are not taken into
consideration during testing, since these specifications do not apply to a prototype as
they are already fully satisfied by the design verification.

Table F.4: Performance Testing Descriptions

Performance Specifications Testing Description
Ethernet capability Performance of the Ethernet capability was tested by
streaming multiple audio signals to ensure that multiple
streaming within a network was handled by the overall
system.
Audio streaming Software tools can be used to validate the streaming
digital stereo audio quality of 128kps, but testing analog
audio quality was a subjective procedure. To consider
noise implications at the output of the analog module, we
prepared a pilot tone in MP3 format and tested the analog
output signal using various testing tools.
UPnP Implementation The performance of the UPnP was tested by verifying
that all possible actions are invoked on the module.
User interface The UI for both the PC and the module interface was
tested to ensure ease of use and error-free.
 APPENDIX I
Design Flow

The flow of the design process for this project is not very linear due to the fact
that there are many different components of software and also hardware. There are
uncertainties in the design flow, such as the delay in the shipment of the development
board and many verification stages we must go through in order to ensure the entire
system is operational. The main software components of the design process are the GUI
and the UPnP implementation. This is early in the flow chart since they require the most
amount of time. Also, due to uncertainties related with hardware portions, the hardware
design and prototyping is done long before integrating with the system. For hardware,
we must give enough buffer of time in case of long lead times for delivery of hardware
components.

In terms of our design flow path, although the final integration task involves
simultaneous combination of hardware and software, the fact that software is
implemented onto hardware system, there are slightly different delays for the software
development parts. The software for the embedded system should be completed first due
to a higher chance for complications.

Figure I.1 show a general design flow diagram for implementation of the
complete system. The diagram can be summarized in the following table with its specific
description and its gating functions.

Table I.1: Description of Gating Functions for General Design Flow

Gating Function
Upnp Software Verify
GUI Design Verify
Analog Board Meet Req’s
Complete System Meet Req’s This final gating function is a checkpoint where we
Description
Verifies that the Upnp system performs all the
functionality that was laid out in the design
specification. This includes operation of the services
within the devices.
Ensures that the GUI meets the functional
specifications as far as operation and extent of user
control.
The Analog board must perform as laid out in the
functional specification before advancing.
ensure that all customer requirements have been
satisfied and that the system is free from imperfections
that may cause failure.

I-1
 Design Overall
Architecture

No
Feasible?

Yes

UPnP Software GUI Design / Analog Board

Design / Program Program Design

No No Order Development Order Parts /

Board Prototype

Verify Verify

Delay
Yes Yes
Analog Board
Verification / Test

Merge
Redesign / Re-
prototype

No
Stream Software Combine UPnP /
Meet Req’s?
Design / Program GUI

Integrate
system
Debug

Meet Req’s? No

Yes

Project Complete
Figure I.1: Design Flow Diagram

I-2
 Software Design Flow Diagram
The software design block in Figure I.1 can be further broken down into the
process shown in Figure I.2. The Upnp software design includes designing the software
for the control point and for the devices. An application interface must be designed for
each since the PC GUI will be controlling both a Control Point and a Media Server. The
Upnp software should progress in synch with GUI design since feedback is required to
design the interface between the two. The design flow of the Upnp Device is the same
form as the design flow if the Upnp Control Point up until they merge with testing of the
Upnp system. The first gating function is so ensure that we provide all the functionality
needed to discover devices, send actions, request subscriptions, etc… as well as maintain
enough metadata to properly utilize the services within the devices. The second gating
function ensures that the interface exposed by the Upnp application is appropriate for use
with a GUI. This gating function required feedback from the GUI design team.

Design Upnp Design Upnp

Device Abstraction Control Point
Layer Abstraction Layer

NO NO

Includes all Includes all

necessary necessary
functionality functionality

YES YES

Create Specific
Create a control
Devices: Media
point application
Server Media
interface
Renderer

NO NO

Interface is OK Interface is OK
for GUI for GUI

YES YES

Test control point

interaction with
devices

NO

Works as
expected

Figure I.2: Software Design Flow Diagram

I-3
 Hardware Design Flow Diagram
The analog module design block in Figure I.1 can be further broken down into the
process shown in Figure I.3. The basic DAC and amplifier circuit must be designed.
Then, the first gating function check that the chosen development board will support the
protocols chosen for communication with the DAC circuit. The analog module is then
adjusted and filtered as necessary to obtain a high signal to noise ratio. The second
gating function is essentially checks that our design meets produces sound of an
acceptable quality compared to standard benchmarks. If this succeeds, the analog module
is finished.

Design DAC and

amplifier circuit

NO

Interfaces
with chosen
development
board

YES

Optimize design
for high signal to
noise

NO

SNR is
suitably high

YES

Analog Module
Design Complete

Figure I.3: Hardware Design Flow Diagram

I-4
 APPENDIX J
Consultant Sign Off Form and Memo

Current Status of the Design Project:

Completions:
• UPnP implementation: Control Points, Media Server/Renderer, Media
Streaming
• UPnP implementation: AVTransport, Device Detection, State Control
• Axis Developer Board LX setup and configuration for UPnP control points
• Linux device driver: Synchronous serial port and DMA controller for AXIS
• Network protocols: RTP/RTSP – streaming over UDP with TCP control
connection
• Graphical User Interface in Python, and extended to C++ with SWIG
• Graphical User Interface’s Integration with UPnP Control Points
• Analog Device Module: Amplifier, D-A Conversion, A-D Conversion
• Analog Device Module: Full-Duplex Streaming (see Test section)

Partial Completion (lower priority):

• Control Point Module: Half-Duplex Streaming (see Test section)
• Integration from Axis Board’s Defective Serial Port (see Test section)

Future Implementation (for symposium):

• DVD/VIDEO streaming capability
• Remote Control Points: PDA, Remote Control Points
• Wireless Communication
• More features to come…(microwave, video camera…)

Design Changes and Important Issues

• Overall System Testing Modular or in ‘Tup’lar
• Meaning of Duplex was actually Half-Duplex
• Analog Module (Rob) became as important as UPnP Implementations (Dave)!!!
• Lower Priority Issues are moved for future implementation for Symposium –
PDA, Video, and many special features
 1. His professional option whether your verification plan, if executed, would give good coverage
as to whether the design specification and functional specification meet the customer
requirements..

Table J.1: Our verification plan in relation to design specification

Functional Planned Design Comp Implementation Detail
Components Implementation (Y/N)
Control Points UPnP SDK Set Up Y - provide connectivity to an Ethernet network
- Auto-discovery detection function
Media Server UPnP’s Y - when queried, module provides a list of all the media
MediaServer1.0 available on the electronic device and all of the device
capabilities
Media Renderer UPnP’s Y -renders selected media
MediaRenderer

Media Streaming RTP/RTSP Y -module negotiates transfers for the streaming of stereo
protocol audio
-streaming is fast to produce the audio at the original
sample frequency without buffer under-run.
Analog Devices Amplifier, DAC, Y -perform digital to analog conversions for stereo audio
ADC out, and vice versa.
-amplifier
User Interface Python GUI Y -User Friendly GUI
-Interactive Functions

Table J.2: Our verification plan in relation to PRIMARY functional specification

Functional Design Specification Comp
Specifications (Y/N)
Ethernet Connectivity Axis Board + UPnP Y
Digital/Analog Analog Module Y
Conversion

Streaming Media RTP/RTSP protocol Y

Discovery UPnP SDK Y

(Control Points)

Content/Capability UPnP SDK Y

Information (Media Server)
 Table J.3: General Functional Specifications
Item Comp(Y/N) Detail
Ethernet Connectivity Y The module will provide connectivity to an Ethernet
network
Digital/Analog Y The prototype module must be capable of performing
Conversion digital to analog conversions for stereo audio out (and vice
versa). This functionality must be extensible to both input
and output of audio
Streaming Media Y The module will negotiate transfers for the streaming of
stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency without
buffer under-run.
Discovery Y The module will provide the means of discovery when
placed on the network such that a central control point can
keep record of all the modules on the network.
Content/Capability Y The module, when queried, will provide a list of all the
Information media available on the electronic device and all of the
device capabilities.

Table J.4: Mainboard Hardware Functional Specifications

Item Comp(Y/N) Detail
Microprocessor Y 32bit Microprocessor with MMU
Memory Y 8MB DRAM, 2MB Flash for permanent code
DMA Y DMA channels for Ethernet and audio module interface
Communications Y 10/100 Ethernet (IEEE 802.3) with RJ-45 connector. RS232
programming interface. 1 spare UART with RS232
interface.
Serial Data Link to Y Transfer of text data between the module and the electronic
Electronic Device device will be facilitated by a serial link using a UART on
the mainboard. This feature will be used in conjunction with
the parallel control lines.

Table J.5: Analog Module Hardware Functional Specifications

Item Comp(Y/N) Detail
Communications Y Communication to microprocessor using a synchronous
serial interface. Will require DMA channel to support high
volume of data
Output Y Analog output signal suitable for input to audio power
amplifier. Output impedance 500Ohm - 1kOhm. Output
voltage range is +-5VDC.
Response Speed Y The analog module will provide an output signal at a
frequency of up to 128 kbps
Resolution Y The analog module will process signals with a resolution of
at least 8 bits per channel (left, right).
 Table J.6: GUI Functional Specifications
Item Comp(Y/N) Detail
Device/Media List Y This is a hierarchical structure that can be browsed by the user.
First a module can be selected from the list of active modules.
Then, if the module is a media server then the media within that
device can be selected. If the module is a media renderer then it
can be selected as a media destination.
Indicators Y Each module will have a set of indicators or text to give feedback
on the status of the device.
Search Y The GUI will provide a search engine for finding media based on
name, artist, etc… The GUI will maintain current media content
records for all modules to ensure search times of less than 2
seconds.
Transactions Y The GUI will be capable of enumerating all transactions between
modules that are active at the control point. Transactions may be
selected and modified by the user.

Table J.7: Overall relation in meeting customer requirements

Completed? Customer Requirements
Provide network connectivity to a consumer device, by enabling Ethernet
Y capability, which would permit the consumer device to connect to
computers and/or other devices via a home network.
95% (Half- Allow duplex streaming of audio or video media stored on a hard disk of a
Duplex, computer or on any other module equipped devices. Modules must be
synchronous capable of controlling devices in order to coordinate the media streaming.
serial port
problem)
Implement the UPnP interfacing protocol to embrace the gaining popularity
Y of the UPnP standard that would allow the automatic detection of any new
devices on the network.
Implement a user-friendly interface on PCs or module equipped devices that
indexes the available media files on the network and allows fast and easy
browsing of the files. The module will provide detailed information
regarding the media content of the device in a uniform way such that the
Y
contents can be indexed and browsed by a user application. It will provide
detailed information regarding the type and format of media that the
electronic device is capable of rendering and the supported transfer
protocols.
The module must be economically feasible both in terms of cost and labour
Y
time for a manufacturer to integrate it into their existing products.
The module must have a minimal form factor to fit in existing electronics
Y
enclosures without necessitating any additional mechanical alterations.
Y(with The module shall provide a standard interface to the electronic device such
general that manufacturers can easily integrate the module with the existing
Purpose I/O electronic controls, and allow remote operation and serial communication.
 Y (but no The software must be modular so that functionality can be added as needed
auto-update as per the specific application. An auto-update facility must be provided that
facility, but supports automatic software updates making the module transparent to the
optional) user.
Y, it is The module shall also be extensible and capable of supporting additional
extensible custom features beyond the standard interface through spare configurable
and capable I/O lines. The module must be easily extensible to support video media.
to support
extra
features, but
no extra
features
implemented.
Adaptable to control of other consumer electronic devices such as
Y, extensible
microwaves leading to home automation solutions.

Opinion:

2. His professional opinion whether your paper design verification data gives reasonable confidence
the design specification and function specification meet the customer requirements…

Functional Design Implementation Detail

Specifications Specification
Ethernet Axis Embedded The module will provide connectivity to an Ethernet
Connectivity Board (Ethernet network
Module) + UPnP
Digital/Analog Analog Module The prototype module must be capable of performing
Conversion (DAC, ADC) digital to analog conversions for stereo audio out. This
functionality must be extensible to both input and output
of audio and video.
Streaming Media RTP/RTSP The module will negotiate transfers for the streaming of
protocol stereo audio. The streaming will be sufficiently fast to
produce the audio at the original sample frequency
without buffer under-run.
Discovery UPnP SDK The module will provide the means of discovery when
(Control Points) placed on the network such that a central control point
can keep record of all the modules on the network.
Content/Capability UPnP SDK The module, when queried, will provide a list of all the
Information (Media Server) media available on the electronic device and all of the
device capabilities.
Remote Control UPnP SDK The module will be capable of interfacing with the
and Status (Control Points) control circuitry of a variety of electronic devices with
minimal additional hardware adapters.
Data Link Linux Device The module will be capable of receiving data serially
Driver + Axis’ from the electronic device for the capture of media titles
and descriptions.
Synchronous Serial
Port + Media
Server

Customer Requirements Planned Design Implementation

Specification
Network connectivity to a consumer device and computer via Axis Embedded Board (Ethernet
Ethernet module. Module) + UPnP SDK (ControlPoint
+AVTransport protocol)
Duplex streaming of audio (or video media [optional]) stored UPnP (AVTransport)
on a hard disk of a computer or on any media storage (CD, + RTP/RTSP protocol
DVD) of other module equipped devices.
Modules must be capable of controlling devices in order to UPnP MediaServer Library
coordinate the media streaming. UPnP MediaRenderer Library

Implementation of the UPnP interfacing protocol to allow the UPnP SDK (ControlPoint
automatic detection of any new devices on the network and to +AVTransport protocol)
provide all necessary information about the new devices.
Implement a user-friendly interface on PCs or module equipped Python ,
devices that indexes the available media files on the network C++ Callback,
and allow fast and easy browsing of the files. The module will
provide detailed information regarding the media content of the
UPnP Commands,
device in such a way that the contents can be indexed and UPnP MediaServer
browsed by a user. It will provide detailed information Library
regarding the type and format of media that the electronic
device is capable of rendering.
The module must be economically feasible both in terms of Axis Embedded Board (Ethernet
cost and time/labour for a manufacturer to integrate it into their
Module)
existing products.
Analog Module
(DAC, ADC)
The module must have a minimal form factor to fit in existing Axis Embedded Board (Ethernet
electronics enclosures without necessitating any additional Module)
mechanical changes.
The module shall provide a standard interface to the device Axis Embedded Board (Ethernet
such that consumer electronics manufacturers can easily Module) + UPnP SDK (ControlPoint
integrate the module with the existing electronic controls, and
allow remote operation and serial communication.
+AVTransport protocol)
The software must be modular so that functionality can be UPnP SDK
added as needed as per the specific application. An auto-update Python
facility must be provided that supports automatic software
updates making the module transparent to the user.
The module shall also be extensible and capable of supporting UPnP SDK
additional custom features beyond the standard interface Python
through spare configurable I/O lines. The module must be
easily extensible to support video media.
Adaptable to control of other consumer electronic devices such UPnP SDK
as microwaves leading to home automation solutions.

Opinion:

3. His professional option whether your test plan for the constructed design prototype, if executed,
would give good coverage as to whether the constructed design prototype works and meets the
customer requirements.

Opinion:

4. His professional opinion whether whether your prototype/test measurement data gives
reasonable confidence the constructed design prototype meets the customer requirements.

See Appendix H

Opinion:

5. His professional opinion whether your design flow and design plan were properly executed?

See Appendix B, I

Opinion:

6. His professional opinion whether all design changes were justified.

Opinion:
 7. His professional confidence level all primary customer requirements have actually been met.

Table J.8: Overall relation in meeting customer requirements

Completed? Customer Requirements
Provide network connectivity to a consumer device, by enabling Ethernet
Y capability, which would permit the consumer device to connect to
computers and/or other devices via a home network.
95% (Half- Allow duplex streaming of audio or video media stored on a hard disk of a
Duplex, computer or on any other module equipped devices. Modules must be
synchronous capable of controlling devices in order to coordinate the media streaming.
serial port
problem)
Implement the UPnP interfacing protocol to embrace the gaining popularity
Y of the UPnP standard that would allow the automatic detection of any new
devices on the network.
Implement a user-friendly interface on PCs or module equipped devices that
indexes the available media files on the network and allows fast and easy
browsing of the files. The module will provide detailed information
regarding the media content of the device in a uniform way such that the
Y
contents can be indexed and browsed by a user application. It will provide
detailed information regarding the type and format of media that the
electronic device is capable of rendering and the supported transfer
protocols.
The module must be economically feasible both in terms of cost and labour
Y
time for a manufacturer to integrate it into their existing products.
The module must have a minimal form factor to fit in existing electronics
Y
enclosures without necessitating any additional mechanical alterations.
Y(with The module shall provide a standard interface to the electronic device such
general that manufacturers can easily integrate the module with the existing
Purpose I/O electronic controls, and allow remote operation and serial communication.
Y (but no The software must be modular so that functionality can be added as needed
auto-update as per the specific application. An auto-update facility must be provided that
facility, but supports automatic software updates making the module transparent to the
optional) user.
Y, it is The module shall also be extensible and capable of supporting additional
extensible custom features beyond the standard interface through spare configurable
and capable I/O lines. The module must be easily extensible to support video media.
to support
extra
features, but
no extra
features
implemented.
Adaptable to control of other consumer electronic devices such as
Y, extensible
microwaves leading to home automation solutions.
Priority Customer Requirements
Provide network connectivity to a consumer device, by enabling Ethernet
1 capability, which would permit the consumer device to connect to computers
and/or other devices via a home network.
Allow duplex streaming of audio or video media stored on a hard disk of a
1 computer or on any other module equipped devices. Modules must be capable of
controlling devices in order to coordinate the media streaming.
Implement the UPnP interfacing protocol to embrace the gaining popularity of
1 the UPnP standard that would allow the automatic detection of any new devices
on the network.
Implement a user-friendly interface on PCs or module equipped devices that
indexes the available media files on the network and allows fast and easy
browsing of the files. The module will provide detailed information regarding the
1 media content of the device in a uniform way such that the contents can be
indexed and browsed by a user application. It will provide detailed information
regarding the type and format of media that the electronic device is capable of
rendering and the supported transfer protocols.
The module must be economically feasible both in terms of cost and labour time
1
for a manufacturer to integrate it into their existing products.
The module must have a minimal form factor to fit in existing electronics
1
enclosures without necessitating any additional mechanical alterations.
The module shall provide a standard interface to the electronic device such that
2 manufacturers can easily integrate the module with the existing electronic
controls, and allow remote operation and serial communication.
The software must be modular so that functionality can be added as needed as per
2 the specific application. An auto-update (optional) facility must be provided that
supports automatic software updates making the module transparent to the user.
The module shall also be extensible and capable of supporting additional custom
3 features beyond the standard interface through spare configurable I/O lines. The
module must be easily extensible to support video media (optional).
Adaptable to control of other consumer electronic devices such as microwaves
4
leading to home automation solutions.

Table J.9: Performance Specifications of Customer Requirements

Requirements Performance Specifications
Ethernet capability Standard 10/100 Mbps connection; must provide a standard RJ-45
connector for Cat 5 Ethernet cables.
Audio streaming Decode compressed audio signals into PCM digital formats and
convert to analog with a quality that exceeds 128 kbps stereo.
Sounds should be free of any human perceptible distortions.
UPnP Implementation UPnP SDK allows the device to automatically detect other devices
on the network and auto-configures itself to permit integration into
the existing media network.
User interface Remote capabilities should be an intuitive interface that indexes
 media from all capable devices connected to the network, and
allows the user to browse through the media and control them via
the user interface.
Cost Cost of the module should be no more than 10% of the average
cost of an electronic device in which the module would be
integrated. This leads to a nominal cost limit of $80.00
CDN.(estimate?) It would be acceptable if the prototype exceeded
this limit provided the system would meet these cost requirements
in a mass-production situation
Size Overall size of the module should be no larger than the size of a
standard PCI card.

Opinion:

8. List any design deficiencies?

Opinion:

9. Percentage of Design Completed.

Opinion:

10. Description of what was demonstrated for them and what worked.

See First Page.

MEMO: