read our final report - calvin college
TRANSCRIPT
Afa Malu
Bob VanLonkhuyzen
KJ Yoo
Nathan Snippe
Engr 339/340 Senior Design Project
Calvin College
05/08/2013
© 2013, Team 10 and Calvin College
Executive Summary
Übercaster is an innovative new personal broadcaster for those who want to broadcast their music, ideas,
or translations. By utilizing the range of Wi-Fi and the speed of UDP protocol, Übercaster was able to
broadcast any audio signal connected via a 3.5mm jack. It was able to provide a quick and high quality
connection to at least ten Smartphone clients. The Smartphone users were able to download the free
Übercaster app and stream the audio at rate of 320kbps. We anticipated a delay in the stream of at most a
hundred milliseconds, which is barely noticeable by the human ear. One of our design philosophies was
to make the experience as clear as possible, so it was paramount for us to make everything transparent to
our users, thereby gaining trust of our product. Because as engineers, it is easy to add features that doesn’t
make sense to the users. Ultimately our goal is to produce a device that reflects the goodness of God’s
creation. Thereby being good stewards.
The market for Übercaster is focused on a few main groups: public events, tour guides, museums,
translation services and street performers. With these groups, we estimated about 10,000 buyers in our
first year. With this estimated quantity and manufacturing and production research, we were able to get a
quote for about $84 per device from a “one stop shop” manufacturing company called Arcadia Concepts.
At the end of the school year we had a proof of concept working on a development board with power
modules. We designed and produced our own enclosure and smartphone apps.
ii
Table of Contents
1 INTRODUCTION 1
1.1 DEVICE OVERVIEW 1 1.2 TEAM INFORMATION 1 1.2.1 NATE SNIPPE 2 1.2.2 AFA MALU 2 1.2.3 K.J YOO 3 1.2.4 BOB VANLONKHUYZEN 3 1.3 REPORT OVERVIEW 3
2 SYSTEM ARCHITECTURE 5
2.1 OVERALL SYSTEM DESIGN 5 2.1.1 BLOCK DIAGRAM 6 2.2 ÜBERCASTER 9 2.2.1 BROADCASTER 9 2.3 WEB APPS 16 2.4 GOALS 19 2.4.1 DESIGN 20 2.4.2 FUNCTIONALITY 22
3 REQUIREMENTS 25
3.1 FUNCTIONAL REQUIREMENTS 25 3.2 ELECTRICAL REQUIREMENTS 25 3.3 SOFTWARE REQUIREMENTS 26 3.4 PHYSICAL REQUIREMENTS 26 3.4.1 PRODUCT WEIGHT 27 3.4.2 PRODUCT SIZE 27 3.4.3 PRODUCT MATERIALS 27 3.4.4 PRODUCT DESIGN 27 3.5 POWER REQUIREMENTS 28
4 ELECTRICAL SYSTEM SPECIFICATION 29
4.1 DEVELOPMENT BOARD CHOICE 29 4.2 CUSTOM PRINTED CIRCUIT BOARD 30 4.3 POWER SUPPLY SELECTION 34
5 PHYSICAL DESIGN SPECIFICATION 36
5.1 SYSTEM ENCLOSURE 36 5.1.1 CASE DESIGN 36 5.1.2 MATERIAL SELECTION 37
iii
6 PROTOTYPE AND YEAR END DELIVERABLES 39
7 SYSTEM INTEGRATION TESTING 40
7.1 ÜBERCASTER 40 7.2 ÜBERCASTER LATENCY TEST 41 7.3 ÜBERCASTER CLIENT APP 42 7.4 ÜBERCASTER WEB APP 45 7.5 ÜBERCASTER PHYSICAL STRUCTURE 45 7.6 ÜBERCASTER CURRENT DRAW TEST 48 7.7 FCC REGULATION TEST 49
8 BUSINESS PLAN 51
8.1 VISION AND MISSION STATEMENT 51 8.2 INDUSTRY PROFILE AND OVERVIEW 51 8.2.1 COMPETITION 51 8.2.2 LIMITATIONS AND REGULATIONS 51 8.2.3 TRENDS IN SOCIETY 52 8.2.4 THE COST OF ENTRY 52 8.2.5 NECESSITIES FOR SUCCESS 52 8.2.6 PROJECTIONS FOR THE FUTURE 52 8.3 BUSINESS STRATEGY 53 8.3.1 SWOT ANALYSIS 53 8.4 MARKETING STRATEGY 53 8.4.1 TARGET CUSTOMERS 53 8.4.2 CUSTOMER BENEFITS 54 8.4.3 MARKET SIZE 54 8.4.4 LOGO DISPLAY 55 8.4.5 PRICING 55 8.4.6 ADVERTISING 55 8.4.7 PRODUCTION 55 8.4.8 DISTRIBUTION 55 8.5 FINANCIAL ANALYSIS 56 8.5.1 FORECASTING 56 8.5.2 KEY ASSUMPTIONS 56 8.5.3 FINANCIAL STATEMENT 56 8.5.4 BREAK-‐EVEN, REVENUE, AND PROFIT ANALYSIS 58
9 PROJECT MANAGEMENT 59
9.1 TEAM ORGANIZATION 59 9.1.1 DIVISION OF WORK 59 9.1.2 TEAM ADVISORS AND SUPPORT 60 9.1.3 TEAM MEETINGS 61
iv
9.1.4 FILE MANAGEMENT 61 9.2 SCHEDULE 62 9.2.1 SCHEDULE MANAGEMENT 62 9.2.2 CRITICAL PATH 63 9.2.3 END OF THE YEAR SCHEDULE ASSESSMENT 65 9.3 OPERATIONAL BUDGET 66
10 CONCLUSIONS 68
10.1 ACCOMPLISHMENTS 68 10.2 LESSONS LEARNED 68 10.3 CREDITS AND ACKNOWLEDGMENTS 68
11 REFERENCES 70
Table of Figures FIGURE 1-‐1: ÜBERCASTER TEAM FROM LEFT TO RIGHT: ROBERT, AFA, KJ, NATE ................................................................... 2 FIGURE 2-‐1: TOP-‐LEVEL BLOCK DIAGRAM .................................................................................................................................. 6 FIGURE 2-‐2: ÜBERCASTER SYSTEM BLOCK DIAGRAM ................................................................................................................. 7 FIGURE 2-‐3: SMARTPHONE AND MOBILE APP BLOCK DIAGRAM ................................................................................................. 8 FIGURE 2-‐4: BROADCASTER SOFTWARE BLOCK DIAGRAM ..................................................................................................... 10 FIGURE 2-‐5: IPHONE 5 CONNECTING TO THE ÜBERCASTER WIFI CHANNEL .......................................................................... 12 FIGURE 2-‐6: THE MAIN SCREEN OF THE ÜBERCASTER CLIENT APP, ONCE IT HAS CONNECTED TO THE INCOMING STREAM .. 13 FIGURE 2-‐7: UML BLOCK DIAGRAM OF THE FIRSTVIEWCONTROLLER AND SECONDVIEWCONTROLLER ............................. 15 FIGURE 2-‐8: THE WEB VIEWER TAB OF THE ÜBERCASTER CLIENT APP ................................................................................. 16 FIGURE 2-‐9: PYTHON ADMIN WEB APP .................................................................................................................................. 17 FIGURE 2-‐10: PYTHON ADMIN WEB APP LANDING PAGE ...................................................................................................... 17 FIGURE 2-‐11: PYTHON ADMIN WEB APP LOGIN SCREEN ....................................................................................................... 18 FIGURE 2-‐12: PYTHON ADMIN WEB APP CONTROL PAGE ..................................................................................................... 18 FIGURE 2-‐13: PUBLIC WEBPAGE POWERED BY NGINX WEBSERVER ...................................................................................... 19 FIGURE 2-‐14: NGINX LOAD TEST SIMULATION RESULT ......................................................................................................... 19 FIGURE 2-‐15: A STUDY DONE BY ANDROID TO COLLECT DATA ON HOW WIDE SPREAD THE VERSIONS OF ANDROID ARE. ... 20 FIGURE 2-‐16: SUMMARIZATION OF APP MOVEMENT SHOWING SIMPLICITY. .......................................................................... 22 FIGURE 2-‐17: START UP SCREEN FOR THE ANDROID VERSION OF THE ÜBERCASTER APP. .................................................... 23 FIGURE 2-‐18: MAKING SURE THE USER GETS CONNECTED TO THE ÜBERCASTER NETWORK BEFORE TRYING TO STREAM. .. 23 FIGURE 2-‐19: THE STREAMING VIEW OF THE ANDROID APP. ................................................................................................. 24 FIGURE 4-‐1: CUSTOM ÜBERCASTER PCB ................................................................................................................................ 31 FIGURE 4-‐2: CUSTOM ÜBERCASTER PCB ................................................................................................................................ 32 FIGURE 4-‐3: ÜBERCASTER PCB SCHEMATIC ........................................................................................................................... 33 FIGURE 5-‐1: PROTOTYPE ÜBERCASTER (FRONT) ................................................................................................................... 36 FIGURE 5-‐2: PROTOTYPE ÜBERCASTER (BACK) ..................................................................................................................... 36 FIGURE 5-‐3: CAD DRAWING OF ÜBERCASTER ........................................................................................................................ 37 FIGURE 7-‐1: THE LATENCY MEASUREMENT ............................................................................................................................ 42
v
FIGURE 7-‐2: STRESS EXPERIENCED AT DROPPED HEIGHT ..................................................................................................... 47 FIGURE 7-‐3: DISPLACEMENT EXPERIENCED AT DROPPED HEIGHT ........................................................................................ 47 FIGURE 7-‐4: SIMULATED DROPPED ENCLOSURE ..................................................................................................................... 48 FIGURE 7-‐5: THE CURRENT DRAW TEST SETUP ..................................................................................................................... 49 FIGURE 9-‐1: THE TOP LEVEL ORGANIZATION OF OUR FILE SHARING STRUCTURE UTILIZING DROPBOX. ............................... 61 FIGURE 9-‐2: ORGANIZING AND SCHEDULING TASKS THROUGH SMARTSHEET. ....................................................................... 62 FIGURE 9-‐3: EXAMPLE OF HOW WE UTILIZE TRELLO.COM ....................................................................................................... 63 FIGURE 9-‐4: DESIRED CRITICAL PATH FROM FIRST SEMESTER ............................................................................................. 64 FIGURE 9-‐5: DESIRED VERSIONS OF ÜBERCASTER TO BE ACHIEVED BY END OF YEAR. .......................................................... 64
Table of Tables TABLE 2-‐1: SIGNAL IDENTIFICATION FOR FIGURE 2.1 ............................................................................................................... 6 TABLE 2-‐2: SIGNAL IDENTIFICATION FOR FIGURE 2.2 ............................................................................................................... 7 TABLE 2-‐3: SIGNAL IDENTIFICATION FOR FIGURE 2.3 ............................................................................................................... 8 TABLE 2-‐4: DESIGN DECISIONS FOR CHOOSING STREAMING PROTOCOL RELATING TO OUR GOALS FOR THE APP. ................ 20 TABLE 4-‐1: DIFFERENT BOARD SPECIFICATIONS .................................................................................................................... 29 TABLE 4-‐2: DIFFERENT BOARD SPECIFICATIONS .................................................................................................................... 31 TABLE 4-‐3: FACTS ABOUT THE CUSTOM PCB .......................................................................................................................... 34 TABLE 4-‐4: BATTERY COMPARISON ........................................................................................................................................ 34 TABLE 7-‐1: INSIDE RANGE TESTING DATA ............................................................................................................................... 41 TABLE 7-‐2: OUTSIDE RANGE TESTING DATA ............................................................................................................................ 41 TABLE 7-‐3: DROP TEST RESULTS ............................................................................................................................................. 47 TABLE 7-‐4: FCC REGULATION TEST RESULTS .......................................................................................................................... 49 TABLE 8-‐1:ÜBERCASTER FINANCIAL STATEMENT .................................................................................................................. 57 TABLE 8-‐2: ANALYSIS AND JUSTIFICATION OF BREAK-‐EVEN, REVENUE, AND PROFIT .......................................................... 58 TABLE 9-‐1: SUMMARY OF HOURS FOR ENTIRE YEAR. .............................................................................................................. 65 TABLE 9-‐2: OPERATING BUDGET FOR ÜBERCASTER THROUGHOUT THE YEAR. ..................................................................... 67
1
1 Introduction
Have you ever been to a church service that offers translations through the use of FM transmitters? Even
though these systems can be effective, they are unnecessarily expensive and bulkyi. Maybe you’ve also
noticed during museum tours, the guide is barely audible due to ambient noises in the area. Using
Übercaster can solve these problems and more. Übercaster is a small, portable way to broadcast any audio
signal for people to hear better and clearer. It works by taking the audio signal that goes into a normal
headphone jack and broadcasting that signal on a Wi-Fi network to any Smartphone users within range
who have downloaded the free Übercaster app. Imagine the convenience of going to a church service in a
different language and using your phone to receive a translation and getting meaning out of what the
pastor has to say. Or taking a tour at a museum and hearing everything the guide has to say about your
favorite piece of art. One of the motivating goals for this project is to simplify the current method and
implement the less-is-more design. The functionality of the transmitter and receiver system is not reduced
using WiFi, but made more intuitive and is enhanced. Doing so creates every one with a smartphone to
potentially connect and stream. We believe this makes the broadcasting process more transparent to our
users. We believe as engineers, it is our job to make sense of the world through science, experimentation
and mathematics for those who don’t understand. Our goal is to produce a device that resembles and
praises our creator.
1.1 Device Overview
Übercaster is a simple-to-use device with a design comparable to Apple products. The device has limited
buttons and knobs while still achieving its intended purpose being user friendly and recognizable. The
two components to the project are: a router that broadcasts audio through a 3.5mm jack and a Smartphone
app (iPhone and Android). Besides receiving the broadcasted audio, the apps also include features such as
the ability to change the quality and volume of the stream as well as choose between different available
streams. The enclosure of the device provides a 3.5mm jack input for the ability to connect devices like a
microphone, guitar pick-up, mp3 player, etc. The router is easily transported and is fully portable with the
option to plug in to a normal power outlet. It also survives basic weather changes and in case it is
dropped, it survives a 4-foot fall.
1.2 Team Information
Team Übercaster is composed of three electrical engineering students and one mechanical engineering
student (pictured below).
2
Figure 1-1: Übercaster team from left to right: Robert, Afa, KJ, Nate
1.2.1 Nate Snippe
Snippe is an Engineering student with an Electrical & Computer concentration and a German minor. He
loves to travel and experience different cultures and lifestyles. In his free time, Snippe loves to go for a
run or spend time reading a good book. He has been known to collect and attempt repair of several
different kinds of electronics (mainly Xboxes and laptops). After his internship with the United Nations
Scientific Committee on the Effects of Atomic Radiation in Vienna, Austria, he used his learned skills of
programming and group organization and management to help turn Übercaster into reality. Snippe lead
the Android app development and helped organize and manage the team. Snippe is still looking for work
post graduation.
1.2.2 Afa Malu
Malu is an Engineer with a Mechanical concentration and a Math minor and was responsible for all the
mechanical aspects of Übercaster. Even though there are no moving parts to Übercaster, he had a lot to
bring to the table when it comes to material selection and circuit area optimization. His understanding of
electrical components comes from producing office receptacles for Haworth Furniture during his
internship at Innotec located in Zeeland Michigan. Malu’s passion lies in design and analysis of systems,
especially in the automotive industry. He hopes to work in the United States after graduation in order to
further his knowledge, which would eventually be beneficial for his native homeland, Nigeria. Being the
only mechanical engineer in the group, Malu’s efforts were focused mainly on the design of the enclosure
and optimization of the space within the device.
3
1.2.3 K.J Yoo
Yoo is an Engineering student with an Electrical & Computer concentration and German minor. Yoo has
a diverse interest in business, music, languages, technology, and philosophy. He has lived in Stuttgart,
Germany, Seoul, South Korea, and Grand Rapids, Michigan. This past summer, Yoo developed a TV
scheduler using an Arduino and Google Calendar for Calvin Engineering Department. He also has
interned for Porsche Development Center in Weissach, Germany and also at MoNET (The Laboratory of
Molecular Neuroimaging Technology) at Severance Hospital in Seoul, South Korea. He enjoys playing
piano, violin, and guitar in his free time and plays soccer extensively. After graduation, he hopes to work
in the U.S.
1.2.4 Bob VanLonkhuyzen
VanLonkhuyzen is an Engineering student in the Electrical & Computer concentration who is passionate
about using engineering for missions. He is looking forward to designing the hardware at the heart of
Übercaster, and expanding his knowledge of mobile operating system software. He eagerly put to use the
knowledge and experience he gained from both of his previous internships: the research on mobile
technology for the Christian Reformed Church in North America, and his work with Radio Frequency
theory and circuit board layout at the HCJB Global Technology Center. After graduation,
VanLonkhuyzen shall be entering the Calvin Seminar, pursuing a Master of Arts in Missions and
Evangelism. His efforts for the Übercaster team were focused on designing the software for Apple’s
mobile operating system.
1.3 Report Overview
This report explains in detail the Übercaster system and what this device requires with respect to electrical
and power specifications, physical design specifications, system testing, business and marketing plan for
product production, and the management that went into the project.
Chapter 2 covers the system architecture of Übercaster giving a technical explanation of how the device
functions. The product requirements in chapter 3 contain the customer-driven specifications with respect
to all aspects of the device. The electrical system section in chapter 4 contains the different subsystems in
detail including design decisions. The power section in chapter 5 explains the power management
solution. The physical design section in chapter 6 includes a description of the enclosure, the type of
materials, and estimation of the printed circuit board size and layout for Übercaster. The system
integration testing section in chapter 7 describes how the design of Übercaster is evaluated compared to
the goals we had previously set. The business plan section in chapter 8 includes the market information
4
and the team’s financial estimates for feasibility in starting a business. The project management section in
chapter 9 explains each team member’s division of work based on individual expertise, and how the
organization has kept the team on track. The helpful advice given to the team by faculty, staff, and
mentors is also explained in this section. And finally, the conclusion of the project is detailed in chapter
10 explaining the accomplishments and lessons learned. All references will be included in chapter 11.
5
2 System Architecture
2.1 Overall System Design
The Übercaster system consists of three distinct, but related elements: (a) the Übercaster, a physical
device that accepts an audio signal through an audio jack and broadcasts the signal over WiFi, (b) the
Web App, a web page that allows remotely turning on and off the Übercaster, and (c) the Übercaster
Client App, a mobile software application that connects to the WiFi signal of the Übercaster and plays the
streaming audio to the user. The app accepts the audio stream, decodes it, plays, and presents the user
with a webpage that the administrator of the Übercaster can create. We decided on this organization of
elements by breaking the entire system down into parts that could be separated without causing serious
problems in the workflow of each individual of the team. We began with the whole system: the
Übercaster and the apps. Already we found that there was a natural division between the Übercaster itself
and the apps that run on separate devices. This gave us two categories of work to distribute. Since there
are four members of the team, we could split both of these two elements into two more sections to have
an evenly distributed workload. The apps could be divided between operating system, with iOS and
Android being the top two operating systems in use.ii The last division had to be in the Übercaster itself.
Since there was a lack of mechanical work as of yet, it made sense to divide the Übercaster into an
electrical system and a mechanical system. The mechanical system could either be the board layout itself
or an enclosure to surround the board. We eliminated the possibility of designing the board ourselves as
this would be outside the scope of our project, and be beyond the experience and expertise of our team
members. The resulting divisions of the project were therefore two mobile apps, one for iOS and one for
Android, the electronics of the Übercaster, and an enclosure to surround the electronics. Now that the
project was divided up, we could investigate the specifics of each subsystem and create block diagrams
for each. Figure 2.1 shows the block diagram of the overall system’s architecture. Figures 2.2 and 2.3
break down Übercaster and the Client app into their respective system block diagrams. Table 2.1
describes the connections between the blocks in Figure 2.1. Table 2.2 describes the same for Figure 2.2,
and the same for Table 2.3 and Figure 2.3, and Table 2.4 and Figure 2.4.
6
2.1.1 Block Diagram
Figure 2-1: Top-level block diagram
Table 2-1: Signal identification for Figure 2.1
Signal Name Connection Type Number of Signals Protocol
Voice Audio 2 (stereo)
Analog audio in Copper wire 2 Mp3 data frames
Digital audio over WiFi Wireless UDP packets on
a WiFi channel
1 PCM data frames
Analog audio out Copper wire 2 Mp3 data frames
Sound Audio 1 (mono)
Configuration UDP packets on a WiFi
channel
1
7
Figure 2-2: Übercaster system block diagram
Table 2-2: Signal identification for Figure 2.2
Signal Name Connection Type Number of Signals Protocol
Power Signal Copper wire 1 Digital high
Analog Audio In Copper wire 2 Mp3 data frames
Mp3 over http over udp Copper trace on board 1 Mp3 data frames
Digital Audio Over WiFi Wireless UDP packets on
a WiFi channel
1 PCM data frames
Encode command Copper trace on board 1 Assembly command
Host command Copper trace on board 1 Assembly command
Html data Copper trace on board 1 HTML document
comprised of
8
character stream
Configuration Wireless UDP packets on
a WiFi channel
1 Python command
Store new settings Copper trace on board 1 Assembly command
Update settings Copper trace on board 1 Assembly command
Figure 2-3: Smartphone and mobile app block diagram
Table 2-3: Signal identification for Figure 2.3
Signal Name Connection Type Number of Signals Protocol
Digital Audio Over WiFi Wireless UDP packets on
a WiFi channel
1 PCM data frames
Datagram Copper trace in phone 1 PCM data frames
Received data frame Copper trace in phone 1 PCM data frames
Saved data frame Copper trace in phone 1 Mp3 data frames
Digital audio Flash memory 1 Mp3 data frames
Amplified audio Flash memory 1 Mp3 data frames
Analog audio out Copper wire 2 Mp3 data frames
Connection status Flash memory 1 Cocoa command
9
Html data Flash memory 1 HTML document
2.2 Übercaster
The Übercaster receives an audio signal input via a microphone input jack, encodes the data, and
transmits that signal over WiFi to other devices. The device sends live audio over the WiFi channel up to
10 connected signals via Smartphones. For simplicity, our device shall be referred to as the Übercaster
throughout this document.
2.2.1 Broadcaster
The Übercaster was developed using a development board called the Miniand Hackberry A10. A custom
built version of the Linux operating system Linaro 12.06 was installed on the board. While the board had
more components than we need, it fits our needs very well due to a fast CPU, WiFi module, relatively
small size, relatively cheap and an audio input. The software of the broadcaster was developed in the
following way. We custom compiled a Linux OS: Linaro Ubuntu. Linaro is group that is seeking to
optimize Linux OS for ARM System-on-Chips (SoCs). To save memory on the board, we disabled
several functions such as the USB ports and HDMI port so that the CPU doesn’t need to poll. Now that
there was an operating system, we needed to make it a HotSpot so that smartphones or laptops can
connect to it. So we created a DHCP server and installed Hostapd, which is a user space daemon for
wireless access point and authentication servers. So up to this point, any WiFi capable device can connect
to the dev board. It is important to note that for the future, when there will be multiple Übercasters in
close proximity, to avoid congestion, we will use multiple WiFi channels. The default channel is 6; it is
recommended that to avoid congestion a degree of 5 channels be suggested. (i.e. channel 1, 6, 11). We
then wrote a small AVSERVER that took in stream from AVCONV and connected it with clients. In
Figure 2.4, we see the software stack of the Übercaster system.
10
Figure 2-4: Broadcaster Software Block Diagram
It is important to note that the future development of the Übercaster will be based on the Open-Source
development board, Olinuxino A13. Later in Chapter 4, it will be discussed in much detail. The operation
of the Übercaster follows: an external power button turns on the board. When it boots up, an init script
runs automatically setting up the DHCP server, turning on the HotSpot feature, Nginx web server and the
Python Admin web app. This script sets up the various programs used by the Übercaster, which will be
discussed shortly An audio input such as a microphone, mp3 player, or electric guitar, can be connected to
the Übercaster via a standard 3.5mm audio jack on the board. The audio signal is encoded into MP3
format through an open source command line tool called AVCONV.
The application layer of the stream uses HTTP, the Hypertext Transfer Protocol. Originally, we wanted to
use the RTP, or Real-time Transport Protocol. Our goal for the transport stream was to minimize the
latency of data communication between the Übercaster and the client mobile app. We found that RTP
achieved the lowest latency of many other protocols. This is because RTP is unidirectional
communication: the datagrams are sent from the source with only a timestamp to determine what order
11
the datagrams are to be arranged. There is no communication back to the source to ensure that all the
datagrams were received, or for requests of additional data. The protocol focuses on sending the data and
does not care what happens after the data is sent. Because of the lack of extra safeguards and
informational data, the essential data is transferred much faster. However, because of problems that will
be discussed in the next section, we decided to use HTTP instead. This choice sacrifices some latency to
gain better usability and integration with mobile operating systems.
An HTTP connection is initiated with an IP address and a port number. In our case, we also opened the
connection with path to the streaming mp3 file in the Übercaster. The client app sends a request to the
Übercaster consisting of ascii characters in a document and terminated with both a carriage return and a
line feed character. As dictated by the protocol, the Übercaster responds with a byte stream of ascii
characters that make up a message in HTML.iii
The data stream is finally sent to the WiFi module on the board, where it is transmitted over a WiFi
channel. The Übercaster continuously streams the audio packets, but the connection with the mobile
device is initiated when the mobile app opens. The Client App has the source port of the Übercaster
hardcoded into it, to effectively require the app to be the only method of accessing the stream. Once
connected, the app receives the datagram packets. The connection is terminated when the user either
disconnects from the WiFi channel or disconnects from the stream within the app.
The software for the users to interact with runs on smartphones using the Google Android operating
system or Apple iOS. The smartphone connects to the WiFi channel just as it would to any WiFi channel,
as shown in Figure 2.4. The difference is that the user will not receive content from the World Wide Web,
but rather audio data transmitted over the channel.
12
Figure 2-5: iPhone 5 connecting to the Übercaster WiFi channel
When the user opens up the Übercaster app on iOS, the app initializes and waits for the user to tell the app
to connect. The app connects to the Übercaster stream using a predefined IP address and port number.
Figure 2.6 shows the main user interface the user interacts with. It is not possible to accidentally connect
to multiple streams at once if there are several Übercasters in the vicinity, as each Übercaster broadcasts a
different WiFi channel, with unique SSIDs. Since smartphones can only connect to one WiFi channel at a
time, the smartphones are by nature limited to connecting to one Übercaster at a time.
13
Figure 2-6: The main screen of the Übercaster client app, once it has connected to the incoming
stream
Once the smartphone is connected to the WiFi channel and the user opens the app, the app imports
libraries including MediaPlayer and AudioToolbox that include functionality for controlling the volume
of the audio and building audio queues that are used for all the streaming functions. The app then sets up
and builds the user interface. Once this process is complete, the app waits for user input. The user can
press the connect button to begin receiving the audio stream, or change views to either the Web Viewer or
the About page, which are discussed later.
Figure 2.7 shows a block diagram of the code that will now be discussed. When the user presses the
connect button, the app constructs the AudioStreamer. The app takes the hard coded url containing the IP
14
address of the Übercaster, the port number of the stream, and the location of the mp3 streaming file in the
Übercaster and creates an AudioStreamer object. After this, a message is sent to the AudioStreamer object
to start streaming the incoming data. When this happens, the app builds an audio queue that fetches the
data, delivers it to the decoder, and then sends the decoded data to the audio player. The amount of data
that is fetched and decoded is calculated based on the bit rate of the stream. The queue constantly grabs
more data from the stream and delivers it to the decoder until the user presses the disconnect button in the
main UI. At this point, the data coming from the stream is pulse code modulated data. It is a raw audio
waveform described by digital bits. When the audio queue’s buffer fills, a full frame of audio data has
been received. The queue calls the AudioFileStream callback function to deliver the full frame of data to
the decoder. The decoder processes the frame of data as mp3 data and pushes it to the speakers, where the
user hears it. When the user presses the disconnect button in the main UI, the streaming process is
terminated and the streamer object and the audio queue are destroyed.
The app also lets the user interact with the stream, as shown in Figure 2.8. The app displays a webpage if
the administrator of the Übercaster has created one. The user can press the “Web Viewer” tab at the
bottom of the screen to view the web page. When the user taps this tab, the second view controller sets up
a web view and sends a load request for the location of the webpage, using the Übercaster’s IP address.
The user can then view the web page and browse whatever content the administrator has published.
The last tab that the user can access is the “About” page. This page displays some information on who
made the app and attributes borrowed code to those who created it.
The idea of transparency played a large role in the development of the iOS app. The interface is very
simple so that the user is not confused about what information the app is relating. At a glance, the user
knows if the app is connected to the stream or not. The user does not need to be bombarded with a lot of
technical jargon, so all of the background information is left out, and only the developer knows this
information by reading the output of the debugging console. There are no confusing extraneous features,
only the web view, which presents the user with useful, and possibly interactive information, enriching
the users experience.
15
Figure 2-7: UML block diagram of the FirstViewController and SecondViewController
16
Figure 2-8: The Web Viewer tab of the Übercaster client app
2.3 Web Apps
Since the Übercaster has no user interface to configure settings such as making the device private or
public, or changing the bit rate of the broadcast. It was necessary to have an Admin control application to
change the bit rate of the broadcast. Rather than developing a separate app for Admin control. We decided
17
to implement a secure webserver, which allows anyone connected to the Übercaster to login with an id
and password to control the device. This web was built using a python micro framework called Flask. The
block diagram of the admin app flow is shown in Figure 2.9.
Figure 2-9: Python Admin Web App
When a secure connection between the admin controller and the device has been established, the admin
controller can then freely turn on and off the stream and set the bit rate. There are pros and cons to
building a web app. The pros are it is inexpensive and very easy to setup. It also keeps our philosophy of
keeping the design of the Übercaster as simple as possible. The web app enables any device connected to
it to be potentially an admin control device. It is important to note, even though universal admin control
potential might be convenient, it can pose some serious vulnerability issues if the device lacks secure
login sessions. A hacker might easily take over and cause a denial of service attack. It was very important
when the web app was created to have a secure login mechanism. This was done by Flask by using the
Werkzeug providing a 'secure cookie' as session system. In Figure 2.8, 2.9, 2.10 show the user interface of
the Python Admin web app.
Figure 2-10: Python Admin Web App Landing Page
Access Admin Page (http://
10.0.0.1:5000)
Login by typing custom set I.D and P.W
Control the device
18
Figure 2-11: Python Admin Web App Login Screen
Figure 2-12: Python Admin Web App Control Page
Some other feature of the web app is the public webpage. An Nginx webserver was setup to serve simple
html pages as demonstrated in Figure 2.11. Since the web page must handle at least 10 clients, a server
load simulation was done using the Apache Benchmarking tool to prove that the webserver is able to
handle it. Just as a safety factor I tested the server by having 30 simultaneous requests 10 times. In Figure
2.12 shows the simulation result. The results show that the average time handling the requests is 995ms.
19
Figure 2-13: Public webpage powered by Nginx Webserver
Figure 2-14: Nginx Load Test Simulation Result
2.4 Android
2.4.1 Goals
The drive behind Übercaster is to empower anybody to broadcast anywhere. In order to do this,
Übercaster has been designed to be transparent to easily facilitate a person’s approach to technology.
Therefore, the Übercaster Android app, like the iOS app, has a simple and basic UI design to provide an
easy understanding of its functionality.
20
Keeping in mind each potential user, Übercaster must also be caring by providing making sure
broadcasters do not have unnecessary limitation to their broadcasting audience. It is important to include
as many people as possible in the ability to receive the broadcast. This means that it is ideal for the app to
be functional on Android devices that run at least Android version 2.3.3 of Gingerbread (API 10) and
above since it is currently the most used version of Android (Figure 2.15).
The final goal is to provide a trust to the user by designing a reliable app. This includes extensive testing
of the main functions like limiting the latency of the stream at much as possible. Many applications of
Übercaster require live streaming which therefore requires a fast latency of around 100ms. Übercaster
was designed keeping this in mind so that people with live streaming applications can trust that
Übercaster will provide what they need. This goal proved to be the hardest to achieve and in the end, the
latency requirement could not be met with the time allotted.
Figure 2-15: A study done by Android to collect data on how wide spread the versions of Android are.iv
2.4.2 Design
The design process of this app can be seen as very iterative. Table 2-4 shows different internet protocols
relating to the goals of the device. A ‘1’ represents a correspondence with the goal while a ‘0’ means that
21
the goal could not be achieved under those implementations. Initially, the design called for receiving an
RTP stream because it was researched to be the best in each of the three different types of protocols.
Unfortunately, this was later found out to be false. The Version Availability requirement could not be met
with the RTP library for Android (android.net.rtp) since it was released for API level 12 and above
(Version 3.1 for Honeycomb). From the study done by Android shown in Figure 2-15, implementing this
would mean not being able to reach 39.7% of the android population. Loosing this chunk of the
population would not be caring to the users so we either had to spend valuable time trying to implement
third party source code or change the communicating protocol. We decided that it is better to sacrifice the
latency and have a working app than to have to take the chance that the app would not be functioning at
all by the end of the semester.
Table 2-4: Design Decisions for choosing streaming protocol relating to our goals for the app.
Goal Req. RTP w/ 3rd Party Lib RTP w/ Native Lib RTSP HTTP Speed/Latency 100ms 1 1 0 0 Easily Implemented -‐ 0 0 1 1 Version Availability ≤2.3.3 1 0 1 1 User Ease of Use -‐ Not Effected Not Effected Not Effected Not Effected
Once we made this design decision, we moved forward with the Android app development using
Android’s native library android.net.rtp. It wasn’t long before we discovered problems while trying to use
this library. An app was programmed with android.net.rtp to receive, decode, and play the RTP stream,
but nothing could be heard. After hours of debugging and consulting other Android developers, we found
that the problem was with the mp3 codec which the audio is encoded with by the Übercaster device. The
codec is not supported by the RTP library in Android and the only potential way to build an Android app
that receives an mp3 encoded RTP stream is to download the data into a local buffer and converting it to
the right codec. Doing this will significantly increase the latency of Übercaster and it will lose the “live”
characteristic which we desirev as well as become significantly more difficult to implement. In order to
stay true to our deadline, we decided to switch from using RTP to using RTSP to stream the audio signal
since the latency in the stream was already compromised. As Table 2-4 shows, we expected it to be easily
implemented with the native Android library as well as available with all Android versions. Losing the
ability to live stream effectively was the sacrifice we had to make in order to get the app completed in
time. After switching to RTSP, Android's native media player library was able to be implemented in order
to receive and decode the stream.
22
2.4.3 Functionality
A summarizing block diagram of the movement within the app can be seen in Figure 2-16. When the user
opens the app on their Android device, a screen with the Übercaster logo appears with two buttons at the
top right of the screen called “Connect” and “About” (Figure 2-17) where the user can choose to connect
to a broadcasted stream or connect to the Übercaster web server and read whatever the broadcaster has
posted whether it be a biography or a donation page. When choosing “Connect”, the user will be asked to
connect to the Übercaster network before calling the streaming class (Figure 2-18). If the user already
connected, the “Connect” button brings them straight into the streaming activity. If connected to a
broadcasting network, the app will then begin streaming whatever is being broadcasted when the ‘play’
button is pushed which gives the application the hard-coded URL which has the broadcasted audio
(Figure 2-19). When in the streaming screen, the user has the option to go back or to pause (which turns
into a play button after being pressed), stop, or refresh the signal. Each signal calls the build in function
of the android MediaPlayer corresponding to each application. The user can also push the “Change
Network!” button and be able to go back into the WiFi settings to change the stream that is received if
multiple networks are available.
Figure 2-16: Summarization of app movement showing simplicity.
23
Figure 2-17: Start up screen for the Android version of the Übercaster app.
Figure 2-18: Making sure the user gets connected to the Übercaster network before trying to stream.
24
Figure 2-19: The streaming view of the Android app.
25
3 Requirements
For a clear summary of what the Übercaster is capable of, the following requirement sections details the
project’s goals.
3.1 Functional Requirements
REQ 3.1a: The device shall have a power on/off button
The users can easily turn on and off the device within 5 seconds
REQ 3.1b: The device shall broadcast audio
The audio quality is better than radio. The users can comfortably listen to high quality audio
REQ 3.1c: The device shall be able to last at least 4 hours of broadcast time
In most situations, we believe that the broadcasting time will fall below the 4-hour mark
REQ 3.1d: The device shall be able to connect at least 10 clients
REQ 3.1d: The device shall have delay of no more than 100ms
It is very hard to listen when there is a delay more than 500ms due to the mismatch in visual and
auditory. We believe that 100ms is small enough that the users will not notice the delay.
REQ 3.1e: The device shall be water resistant (to rain not immersion)
The device will be used outside extensively, so it is important that it is weather resistant to rain or
snow.
3.2 Electrical Requirements
REQ 3.2.1a: The device shall have a 3.5mm audio input and a power adapter plug.
3.5mm audio is widely used so it is important that this is used. Power adapter plug is needed to
recharge the battery.
REQ 3.2.1b: The device shall use WiFi communications and the content shall be sent via the UDP
REQ 3.2.1c: The device shall be able to withstand a drop from 4ft onto a concrete surface.
Since the device will be carried around or used outside extensively, the device should be durable
just in case the users drop or step on the device.
26
REQ 3.2.1d: The device shall be able to remain operational in temperatures ranging from -20oC to 60oC
The device potentially can be used in various scenarios and environment. It is important that the
device functions well in both extreme cases.
REQ 3.2.1e: The device shall not radiate more than what is said on the FCC guideline
To be sure that the WiFi radiation will not hinder the users and surrounding public, FCC makes
sure that that radiation emission is below their limits.
3.3 Software Requirements
REQ 3.2.3a: The app shall decode the UDP packets from the Übercaster.
The device sends the data using UDP, so it is paramount that the app is able to decode it.
REQ 3.2.3b: There shall be a separate iPhone and Android app for the Übercaster.
The market for iPhone and Android is large for both, so the potential reach of Übercaster can be
significantly increased by developing for both platforms
REQ 3.2.3c: The app shall have a volume control and be able to choose a different channel.
The app should be simple, but the simple functions should be very functional. Different channel
choice can allow a user to switch Übercaster network’s to stream different audio.
REQ 3.2.3d: The device shall run a custom Linux distribution.
Linux is very malleable in the sense that it is easy to develop upon. It is free and has a large
development community that is very active. Linux also allows a sensitive control in the hardware
system.
REQ 3.2.3e: There shall be a web app for the Übercaster
The owner of the Übercaster should be able to control his or her device easily. By implementing a
web app, anyone can easily control the device with the right information
3.4 Physical Requirements
The physical design of Übercaster is to provide easy portability and durability for the user.
27
3.4.1 Product Weight
REQ 3.4.1: The device should weigh no more than 0.50 lbs.
The ideal device would eliminate any excess weight for greater portability comfort and safety.
0.50 lbs. is low enough that minimal injuries would occur if dropped on a foot. 0.50 lbs. is high
enough for the combined weight of the interior components. A study conducted by Team 10
showed that 0.50 lbs. could be comfortably carried for 4 hours. Having 20 individuals, 10 males
and 10 females of varying age, Team 10 carried out the test where a cardboard that rendered to
the liking of the device weighing 0.50lbs to be carried around for 4 hours. After the 4 hours, they
evaluated the comfort and overall feel of carrying the device.
3.4.2 Product Size
REQ 3.4.2: The device should be easily portable (4.0±0.2in. by 2.5±0.1in. by 1.0±0.2in.)
The product size should be small enough to fit into a small backpack or carrying case.
It is important that Übercaster be portable for street performers who do a lot of moving around.
The device is recommended to have similar dimensions to an iPhone but thicker. Dimensions set
are as Height: 4.1 in. Width: 2.4 in, and Thickness: 1.2 in. The defined size requires that the
layout and size of interior components be minimized as much as possible.
3.4.3 Product Materials
REQ 3.4.3a: The device should be durable (refer to REQ 3.2.1c)
REQ 3.4.3b: The device should be water resistant (refer to REQ 3.1f)
REQ 3.4.3c: At least 70% of the device should be recyclable
REQ 3.4.3d: The device should be UV resistant
3.4.4 Product Design
Both the interior and exterior design of Übercaster was done in Solidworks. All team members were
responsible for designing what they thought Übercaster should look like. The options were considered
and the best one (potential component fit, and aesthetical appeal) was chosen. The interior components
were not fully determined (size and geometry) when the external design was made. Solidworks rendering
of the parts were made once they were determined. The parts were then laid out to fit in the previous
external enclosure designed.
28
REQ 3.4.4: One part of the device should not be substantially heavier than the other.
It is important that there is even weight distribution within the device for comfort. The component
l ayout can be assembled to optimize the space available.
3.5 Power Requirements
REQ 3.5a: The device should last a minimum of 4 hours.
Übercaster is built to last a minimum of 4 hours. The longest activity projected is street
performing. The 4-hour minimum would be sufficient for a performer who takes breaks and can
charge the device during that time.
REQ 3.5b: The device must have an in-built rechargeable battery and an attachable power cord.
REQ 3.5c: Übercaster should also be usable on battery only or when plugged in.
29
4 Electrical System Specification
The electrical system specification will concern the development process of the Übercaster device.
4.1 Development Board Choice
Our development board was chosen from the following aspects: fast CPU, WiFi module, audio input
feature, presence of a development community, reasonably priced and relatively small. While iterating
our design specifications for what we decided Übercaster needed, several different development boards
were considered for developing our prototype. We started with boards made by Mini-Box and Olimex and
after using these boards we realized that the Mini-Box and Olimex boards did not provide the
functionality and performance as we expected it to. After a long search and knowing the required
performance, the Miniand’s Hackberry A10 was the choice because it beat the others in CPU and WiFi
performance and of course the presence of an audio input, which were the three main required
components, needed for the Übercaster. From Table 4.1, it is seen that the Hackberry’s A10 has all the
necessary components with a faster processor, more memory, a smaller size, and consumes less power
than our other choices. Unlike the other boards, the Hackberry has a built-in WiFi module, which can
transmit and receive up to 150Mbps, which is more than enough for our project. The Hackberry was the
obvious choice.
Table 4-1: Different Board Specifications
Board Hackberry A10 Olimex Olinuxino A13 pico-SAM9G45
CPU 1.2GHz Allwinner A10
ARM Cortex A8
A13 Cortex A8 processor at 1GHz,
ARM9, 400Mhz,
ARM926EJ-S, 32/32K
Audio input 3.5mm microphone jack 3.5mm microphone jack NONE
Memory DDR3 1GB, ~100MB is
reserved for the GPU
512 MB RAM
256MB DDR2
Boot Boot from SD card and
internal storage via u-boot
Boot from Micro-SD card Boot from Micro-SD
card
Power NEMA 2-pin power 6-16VDC input power supply, 6-40V support via DC
30
adapter included Input
AC100-240V-0.4A
50/60Hz Output DC5v
noise immune design
barrel connector
Size 110 x 80 mm 120 x 120 mm 80x100mm
Power
Consumption
With 3A Li-Ion Battery, it
lasts 5 hours (drawing
500-700ma)
No Info Given No Info Given
WiFi Module WIFI 802.11n 150Mbit Not Built-In Not Built-In
Cost $65 $60.35 $69
Even though there are different kinds of development boards, the Miniand Hackberry A10 fit our need the
best due to having a fast CPU, WiFi module, Audio Input and reasonably priced and small sized.
4.2 Custom Printed Circuit Board
Now that the proof of concept worked, if Übercaster ever went into full production, we would need a
custom PCB that tailored only to our needs. A custom PCB was developed using EagleCad. It is a very
popular tool to develop and design printed circuit board. After consulting with Prof. Kim, our team
realized that it was impossible to create a PCB with this high frequency, time constraint, lack of in-depth
experience and budget. He gave us an estimate that it would take at least 6 months to develop such feat. It
was clear that we couldn’t design a custom PCB board in the given project duration from scratch. So we
decided to adapt and modify an open source PCB by Olimexvi. We chose the A13-Olinuxino version to
base our design. Allwinner’s A13 is an inferior chip compared to the A10 model in the sense that the
video processor in A13 lacks a lot of features from the A10 model. Since video processing was not in our
scope, we chose A13 because it was cheaper. We also realized that not that much memory is required to
run the Übercaster. So even though A13 has a maximum of 512MB RAM it wasn’t an issue. Now using
the A13-Olinuxino as a framework, the designing of the Übercaster’s PCB process was a series of
massive reduction. Allwinner’s A13 data sheet manual, Olimex’s Board data sheet and schematic outline
were heavily consulted to make a custom PCB that had the sole requirements of the Übercaster. Since the
A13-Olinuxino was developed using EagleCAD already, it was simple in determining which design
software was to be used. Although EagleCAD is not very good at optimizing the board and costs money
for the full suite, from different PCB design software that was free such as ExpressPCB, EagleCad,
31
SunStone, and DesignSpark, EagleCAD was still the choice. It is important to understand that
Allwinner’s A13 is a System on Chip. What this means that it is not just a CPU, but many different
peripherals encased together. In Figure 4.2 the necessary peripherals of the Übercaster’s A13 SoC use is
demonstrated. Using the block diagram that is laid out the custom PCB was developed. In Figure 4.3
shows the Custom Übercaster PCB board layout and in Figure 4.4 shows the schematic layout.
Key components are outlined in Table 4.2
Table 4-2: Custom PCB Specifications
System on Chip (SoC) Allwinner A13 (Cortex A8 processor running at 1Ghz)
WiFI Module WM-294 (WiFi 802.11n 150Mbit WIFI module)
Memory Hynix H5TQ1SG833BFR (4 x 256MB x8 with two 2Gbit chips)
NAND 4GB
Audio Input AC97
Power AXP209
Figure 4-1: Custom Übercaster PCBvii
32
Figure 4-2: Custom Übercaster PCB
33
Figure 4-3: Übercaster PCB Schematic
Some quick facts about the custom PCB are organized in Table 4.3
34
Table 4-3: Facts about the custom PCB
Number of Layers 4
Maximum signal speed 1.5Ghz
Total board area 22.09 Inch^2
Part count 244
1 PCB production cost $154viii
Cost of Complete Prototype Manufacturing with Enclosure
and Packaging @10,000 units
$84.00 per unit*
*The cost will be explained in the Business Plan section in Chapter 8
4.3 Power Supply Selection
A Lithium-Ion (LI) battery is to be used for the Übercaster. Two other battery types were considered:
Nickel-Metal Hydride (NiMH) and Nickle Cadmium (NiCd) battery. The criteria considered can be found
bellow in Table 4.4. Positives for the LI battery were its high charge/discharge efficiency, its self-
discharge rate, its lack of maintenance, and non-hazardous disposal. The cons were its less desirable
operating temperature than NiMH, and its lower maximum charging cycle. We decided that the pros
outweighed the cons so went for the LI.
Table 4-4: Battery Comparisonix
LI-ion NiMH NiCd
Specific-Energy 100-265 W-h/kg 60-120 W-h/kg 40-60W-h/kg
Energy Density 250-730 W-h/L 140-300 W-h/L 50-150 W-h/L
Charge/discharge Efficiency 80-90% 66% 70-90%
Energy/price 2.5 W-h/$ 2.75W-h/$
Self-Discharge rate per month 18% 30% 20%
Cycles 400-1200 500-1000 2000
Operating Temperature from -20 to 60C from -40 to 60C from -20 to 60C
35
Required Discharge None every 60 - 90 days every 30 - 60 days
Disposal Non-hazardous Hazardous Hazardous
LI batteries are the most commonly used in portable electronic devices. The Dev Kit used for the
Übercaster uses a power input of 5V, which was handled by a rechargeable LI battery. Using the
recommendation, it was decided we use a rechargeable 6000mAh 3.3V LI-PO battery. This battery has
overcharge and short circuit protection, and has dimensions of 50x34x8mm, which is small enough to fit
into the Übercaster enclosure.
The Dev Kit used has a built in LI-PO charger that charges the battery to 100% once the battery is
detected. There is also a power jack that can be used. The kit accepts a voltage range of 9-30V and has a
DC/DC implemented that keeps the power consumption constant no matter what voltage is used. This
eliminates the need for a voltage regulator.
36
5 Physical Design Specification
5.1 System Enclosure
The system enclosure houses the Übercaster electrical and hardware components. It will be designed to be
aesthetically pleasing and to meet the previously discussed physical requirements.
5.1.1 Case Design
The prototype Übercaster’s visible features include a 3.5-mm jack for a microphone or other device (e.g.
guitar), a power button, and a power cord charger port. An image of the prototype can be seen in the
below figures. If Übercaster was to go into the market a few variations would be made. A mini USB
charging port would be substituted for the current power jack, and broadcast/connected indicator lights
would be added to the top of the case. A CAD rendering of the potential final device can also be seen
below.
Figure 5-1: Prototype Übercaster (Front)
Figure 5-2: Prototype Übercaster (Back)
37
The indicator lights were initially supposed to represent the number of devices (smartphones) connected
to the Übercaster but our estimates of a maximum of 10 people connected was surpassed. Since over 200
people can connect to the device, and having over 200 lights on the device did not support our “clean”
design, the function of the indicator lights changed from indicating how many people to notifying the
Übercaster user that audio was being broadcast.
USB chargers are very useful for their versatility. Most small electrical devices today have USB chargers
which make it very easy for an individual to access a charger even if theirs is not available. We need to
care for our customer and having a USB charger does that by reducing the possibility of them losing
power to the device without them being able to charge.
Figure 5-3: CAD Drawing of Übercaster
5.1.2 Material Selection
We decided that a plastic be used for the enclosure because of the combined durability, impact absorption,
and ease of molding most plastics have. The potential plastics considered for the production of Übercaster
were ABS (Acrylonitrile Butadiene Styrene), Noryl, and, High Density Polyethylene (HDPE). All three
materials met the physical requirements for Übercaster, but HDPE has a much lower Modulus of
elasticity (170,000psi) as opposed to ABS (320,000psi) and Noryl (350,000psi) so that option was
dropped. ABS is the least expensive option for a large volume. Noryl costs $0.35/lbx, and ABS costs
38
$0.30/lbxi. Though the price difference between ABS and Noryl is not that much, ABS was eventually
chosen because of its availability.
ABS is the most widely used plastic in the production of enclosures. It is used for its strength and
toughness as well as its low water absorption, which is important for changing weather conditions. It is
also a recyclable material an important goal for being a good steward of this Earth. The drawback of ABS
is that it does not do well with UV exposure.
To take care of UV rays, three options were considered: 1) The enclosure could be sprayed with a UV
resistant paint 2) Black Carbon, which is UV resistant, could be added to the ABS which would protect
the enclosure 3) The enclosure could be encased with an aluminum cover.
Coating the device with paint would be cost effective (11 oz can/$10xii) however it would not be practical
for coating a large number of devices being manufactured because of the time it would take to adequately
coat each device. It is also not a permanent fix.
Adding black carbon, which cost $2.2/kg, to the ABS resin used to make the enclosure would be a good
option because not only does it effectively deal with UV exposure, it also increases the tensile strength of
the material from 37 MPa to 52 MPa. The drawbacks to using black carbon are 1) it increases the
percentage of water that might get through the enclosure (from 0.023% to 0.11%xiii). Much literature
cannot be found on the effects black carbon has to ABS but what has been found says that the material
becomes more brittle.
An aluminum outer case would be cost effective and it would provide 100% water resistance as well as
adequate UV protection.
Using an aluminum cover would be the best option for protecting the enclosure from UV exposure.
39
6 Prototype and Year End Deliverables
Over the course of the 2012-2013 school year, research and development was done by Team 10 on
Übercaster. By the end of the year, there was a functional device.
The device was able to broadcast at least one audio signal to the Smartphone of at least 10 people within a
248ft range. The Android app was completed and uploaded onto Google Play Store, while the iOS app
was also completed but was not uploaded to the Apple App Store. A prototype enclosure made out of
high strength Arcylic was built that adequately housed all the internal electrical and hardware
components. A plan of action to proceed with Übercaster as a business, post graduation, was also
included in the final deliverables.
40
7 System Integration Testing
Because there are three discrete parts that work together closely, we tested all parts separately and in
conjunction to ensure that the entire system works as expected.
7.1 Übercaster
We began our testing of the Übercaster by testing the AVCONV program. This program has a utility built
in that gives a visual representation of the data coming into the program. On the Übercaster board,
AVCONV can visualize the audio data coming in through the audio port. With a screen connected to the
board via HDMI, we used this to determine if audio data is reaching the board and CPU properly, and if
the AVCONV program is properly receiving the data. We then used laptops with Linux and AVCONV
installed on them to receive the streaming audio from the Übercaster and play it. Here too, AVCONV
gives a visual representation of the incoming data, as well as plays it. The combination of these two
feedback systems allowed us to determine if the Übercaster was streaming audio properly. It also allowed
us also to test the delay of the audio broadcast. While the board is streaming the audio data, we took two
or more laptops, connected them to the Übercaster’s WiFi channel, and began to receive and play the
stream. We could hear immediately if the delay was noticeable to the human ear. If it was, we could
measure the delay. For example, we connected an electric guitar to the Übercaster and played a riff of
quickly changing notes. The delay is easily heard if the quickly changing notes do not match or overlap
other notes. The delay could be estimated or measured with a precise stopwatch, if the delay as long
enough for human hand mechanics to react to the changes. In our tests, the delay was not large enough to
be consistently noticeable to the human ear.
In our second round of tests, we discovered that VLC, a multipurpose media player available on OSX,
Windows, and several flavors of Linux, was capable of playing UDP streams. We used a MacBook Pro
with VLC installed on it to test the range in an environment with walls as obstacles in the way. One team
member placed the Übercaster on a chair at one end of the Calvin College Engineering Building. A
second team member carried the laptop at stomach level and walked at a constant and even pace away
from the first team member. A third team member held an imperial measuring roller to measure the
distance the second team member walked form the first team member. The third team member walked
with the second team member throughout the testing. Both team members listened to the audio playing on
the laptop and waited for a break in the audio. We considered a sufficient break in audio to be half a
second in duration. Once a break was heard, the two-team members walked at a slower pace until the
audio signal was completely lost. The distance was then recorded in a table. This measurement represents
41
the boundary of the maximum broadcast range. Table 7.1 below contains the data taken during this
testing.
Table 7-1: Inside range testing data
Maximum Range
218 ft +/- 5 ft
In our third round of tests, we used VLC installed on a MacBook Pro to test the broadcast range of the
Übercaster. We performed our testing in the parking lot behind the Calvin College Engineering Building.
Here, there is a lot of open space to measure the maximum, uninterrupted range of the Übercaster’s
broadcast. One member of our team stood at one end of the parking lot and held the Übercaster at
stomach height. A second member held the MacBook Pro at stomach height and walked at a consistent,
even pace away from the first team member. VLC was connected to the audio stream and playing it. A
third team member held an imperial measuring roller to measure the distance the second team member
was from the first team member. The third team member walked with the second team member
throughout the testing. Both the second and third team members listened to the audio playing on the
laptop and waited for a break in the audio, and then continued walking at a slower pace until the audio
signal was completely lost. This distance was recorded in a table. Table 7.2 below shows the data taken
during this experiment.
Table 7-2: Outside range testing data
Maximum Range
468 ft 2 in
7.2 Übercaster Latency Test
Latency testing was a bit tricky. If the latency resolution was couple seconds, the tests should have been
pretty straightforward, but due to the resolution being couple hundred milliseconds, it was clear that a
finer detection testing was needed. Through a creative process that we developed, we were able to get a
very precise measurement of the latency. This is how it works. Avplay, a command line tool, produces a
visualization of the sound input on the Hackberry A10 dev board. We had a sensitive microphone plugged
into the input of the dev board. So by broadcasting and then locally playing back the audio, we got an
42
instantaneous response of the audio. Now we have a client that is connected and streaming audio. Now
here is the part that got interesting, the Avplay has a moving bar that refreshes everything in its path. On
my 22 inch TV screen, it took the bar about 10.26 seconds to go from one end to the other. Now when we
spoke into the microphone, we got an instantaneous response on Avplay, a white mark. After a brief
moment, we got a sound on the client device and the mic picks up the sound. We essentially looped the
audio to determine how long it took to go around the circle. (See the picture below) So then by simple
division, we were able to get a good estimation of the latency. It is important to note that the latency
varied from 75-300ms. We believe this was due to missing packets and buffering.
Figure 7-1: The Latency Measurement
7.3 Übercaster Client App
Testing the mobile app began by ensuring that the app builds without errors. Making sure that the code is
syntactically correct is an essential, but often overlooked, facet of testing. Once the app is built, it was
loaded on to one or more testing devices. For the iOS app, a 4th generation iPod Touch using the armv7
architecture and running iOS 5.1, and an iPhone 5 using the armv7s architecture and running iOS 6.1
were used for testing. We were able to learn a lot from this first test. Whenever any change was made to
the app, it was built and run on a test device to ensure that the changes worked as expected. For example,
we wanted the volume slider on the screen to integrate with the volume buttons on the side of the Apple
device. After adding the proper code to perform the task, the app compiled and built correctly. But when
the app was run on an actual device, there were two volume sliders on the screen. This showed us that
43
even though the code was syntactically correct, there was a problem with our implementation of the code,
and this had to be changed. We deleted one of the volume sliders form the storyboard and unlinked its
code from the volume view, and then recompiled and rebuilt the app. When we ran it on a device the
second time, there was only one volume view and it worked properly. The second part of our testing was
to make sure that the app could run not only on different operating systems, but on different architectures
and different screen sizes. The app was optimized for use on iOS 5.1 and later and to run on both the
armv7 and armv7s architectures. It also has the capability of shifting elements on the screen to properly fit
on both the 3.5” and 4” screens. Now that Apple has devices with two screen sizes, apps must be able to
support both of these sizes. This is important not only to be competitive in the App Store, but to maintain
our design norm of caring. By supporting many different device screen sizes, many operating systems,
and many architectures, users do not need to go out and spend money to buy new devices that are able to
run the app. They can use the technology that they already have. For the people that have the new
technology already, they do not have to worry that the app will not run properly or look bad because it
supports old hardware or different screen resolutions. Users can be confident that no matter what device
they use, the experience will be the same across any device.
Next, the app was tested to see if it was accepting the audio stream data from the WiFi channel. This was
done by adding some code to the app that printed to the Xcode terminal information about the data frames
received, such as frame byte size and presentation time. If no data showed up, no debugging information
was printed. Also, this testing phase was only implemented when testing RTP streaming. We learned
from this phase of testing that RTP would not fit our needs as we had originally thought. The amount of
time and effort that it took to get the app to a point that it could be tested for stream receiving
functionality was too great and would not give leave us enough time to complete the app by the end of the
semester. We decided to change from RTP to RTSP streaming. These two streaming protocols are similar,
but community documentation for RTSP exists in much larger volumes and is much more understandable
than that for RTP. The next phase of testing occurred after the transition to RTSP streaming. We tested to
make sure that the transition did not break any functionality that was in place and working for RTP
streaming. The app still received the frames of data from the WiFi stream, and the debugger output
showed that this worked. Once the app received the data frames as it did before the transition, the next
phase of testing was performed to see if the frames were being decoded and could be played back to the
user. When the audio queue and decoder were written and integrated, some code was added to display a
message when a frame of data was decoded. It was not necessary to add any code to test if the decoded
frames were being played as we only had to simply listen to the device to hear if the playback was
working properly. After building the app and running it on a device, we connected it to the Übercaster
44
network, played music through the Übercaster, and pressed the connect button in the app. The app printed
debugging messages for both receiving the data stream form the Übercaster and for decoding the data.
But on listening to the device, the sound coming from it was not the music that we should have heard, but
static noise. We learned from this test that the data was being decoded, but not in the right manner. The
decoding process had to be changed to properly decode the frames. We also learned from this test that,
while we were able to make significant progress in using RTSP streaming instead of RTP streaming,
using the real time streaming protocol would still take longer to finish implementing than the time we had
left to complete the project. As a result, we decided to switch the protocol once again from RTSP to
HTTP. Our reasoning for this switch was that both Apple and Android natively support HTTP streaming,
and there was significantly more documentation on the use of HTTP streaming as a result. There was still
a problem, though. HTTP streaming has a higher latency than RTP and RTSP streaming. We made the
design decision to sacrifice some latency for ease of implementation. Instead of using third party libraries,
we could use native libraries provided by Apple and Android to implement the streaming, and therefore
have a usable app sooner than using the live555 or ffmpeg libraries. Once the http streaming code was
written, we began our next phase of testing. Because the framework of HTTP streaming is highly
documented by Apple, we decided to take a risk and skip right to testing if the decoding and playback of
the app worked. We played music through the Übercaster, started up the app and connected to the stream
as before, and we listened for the sound that the app would play. The app played exactly what was being
input to the Übercaster’s audio jack. Admittedly, this last test could have been performed more
recursively and thoroughly, but out gamble definitely paid off in this case, and saved us a great deal of
debugging and testing time that we used to add extra features to the app. One of these features was the
web viewer.
Testing the web viewer was relatively simple. After the code was written for the web viewer, the app was
compiled and built, and run on a test device. After connecting to the Übercaster network, we opened the
app and tapped the web viewer tab. The web page that we had created loaded just as it should.
Finally, an overall functionality test of the app was performed. We wanted to make sure that all of the
separate parts of the app worked at the same time, regardless of what parts were already running, and
what order they were initiated. Our first test checked to make sure that the web view would load if the
audio streamer was running in the first view controller. We did not want switching views to terminate
whatever processes were running in the view. After setting up the Übercaster, we ran the app and
connected to the stream. When music was playing, we opened the web viewer. The web page we created
loaded right away, and the music continued to play without any noticeable gaps or glitches. We then
wanted to run a test for the opposite scenario: loading the web page and then opening a stream. After
45
setting up the Übercaster and force quitting the app so that any previous data was cleared, we ran the app
and opened the web viewer. Once the web page loaded, we switched to the first view and connected to the
audio stream. The app played the stream just as it should, with no problems. This meant that the view
controllers were distinct and could run separately, without interfering with each other.
We then tested the apps to see of hardware differences caused the streaming process to change in any
way. We loaded the app onto the two different test devices that are detailed above: the device running iOS
5.1 on the armv7 architecture and the device running iOS 6.1 on an armv7s architecture. We opened the
app on both devices, connected both to the Übercaster network, and then pressed the connect button on
both devices at the same time. We listened to the audio coming from both devices and determined that the
audio was in sync. We then let both devices run the app for half an hour. At the end of this time, we
listened to the audio of both devices again. We determined that the device with the newer and faster
armv7s architecture was ahead of the other device by a fraction of a second. We decided that this is
acceptable for several reasons: first, the delay is very small and is not significant to cause users any
annoyance. Secondly, users will nearly always have only one device each that they are streaming to, and
therefore will not notice if one device differs from another in stream speed. Third, in the unlikely event
that a user is using several devices, the user would need to stream for a long time in order to notice any
differences in stream speed. While this is a good possibility, the fact still remains that the user will have a
hard time noticing any difference in stream speed.
7.4 Übercaster Web App
We have tested the admin app with the smartphone and laptop. The admin works by the user accessing
the webpage at 10.0.0.1:5000. The user then can input the id and password to login. The user then can
control the Übercaster. The user can turn on and off to minimize battery consumption.
7.5 Übercaster Physical Structure
Testing the physical structure began by fitting all internal components inside the enclosure. Once this was done, the device was weighed to make sure it was below the specified maximum weight. The weight and other physical attributes were then used to test the durability of the device. Using the following equations
𝑣 = 𝑣!! + 2×𝑔×𝑠 1.1
𝑎 =
𝑣!
2×𝑑
1.2
𝐺! =𝑎𝑔
1.3
𝐹! = 𝑊×𝐺! 1.4
46
𝑃! =𝐹!𝐴!
1.5
Where v is velocity upon impact (ft/s), 𝑣! is initial velocity (ft/s), 𝑔 is acceleration due to gravity
(32.2ft/s2), s is falling distance, 𝑎 is rate of deceleration (ft/s2), d is deceleration distance (ft), 𝐺! is G-
Force, 𝐹! is force at impact (lbf), W is weight of device (lbf), 𝐴! is impact area (in2), and 𝑃! is pressure
exerted on impact area (psi). These equations show the effect of dropping the device on a hard surface
from a height (s). The stress endured by the device due to the pressure would be found using computer
aided design (CAD) software. The actual calculations can be found below.
W = 1 [lbf] Vol = 5.125 [in] · 4.5 [in] · 2.125 [in] s = 4 [ft] g = 32.2 [ft/s2] v0 = 0 [ft/s] d = 0.25 [in] Velocity Upon Impact v = [v0
2 + 2 · g · s]1/2
Rate of Deceleration
𝑎 =𝑣!
2 · d · 1[ft]12[in]
G-Force Gf = !
!
Force of Impact Fi = W ·Gf Surface Area of Impact Ai = 2.125 [in] · 1 / 4 · p · 2 · 0.3 [in] Pressure of Impact Pi = !!
!!
SOLUTION Unit Settings: Eng F psia mass deg a = 6182 [ft/s2] Ai = 1.001 [in2] Cs = 362594 [lbf/in2] d = 0.25 [in] Fi = 192 [lbf] g = 32.2 [ft/s2] Gf = 192 Pi = 191.74 [lbf/in2] s = 4 [ft] v = 16.05 [ft/s] Vol = 49.01 [in3] v0 = 0 [ft/s] W = 1[lbf] Ys = 6160 [lbf/in2]
Solidworks, a design program, was also used to simulate the enclosure being dropped from various
heights. Results of how much Von Miss stress and displacement occurred can be found in the below table
and graphs.
47
Table 7-3: Drop test results
Distance(ft) Von Miss Stress (Mpa) Max Displacement (mm) 4 16.9 0.6 5 18.2 0.63 6 19.8 0.68 7 21.4 0.74 8 22.9 0.79 9 24.3 0.84
10 25.8 0.89
Figure 7-2: Stress Experienced at Dropped Height
Figure 7-3: Displacement Experienced at Dropped Height
10
15
20
25
30
4 5 6 7 8 9 10 Von Mises Stress (Mpa)
Height (ft)
Drop Test Height Vs. Stress
0.5 0.6 0.7 0.8 0.9 1
4 5 6 7 8 9 10 DeYlection (mm)
Height (ft)
Drop Test Height Vs. Max DeYlection
48
To reduce complexity of the testing, it was decided that the simulation should be done with the device
being dropped on an edge which would account for the worst case scenario. If the device passes the test at
its most critical point, then it could be assumed that the rest of the device would endure a drop from the
specified height. An image of the simulated “dropped” device can be seen in the bellow figure.
Figure 7-4: Simulated Dropped Enclosure
Initially, heat vents were considered to be added to the design. Having vents would deal with overheating
of the device; however they would also cause a problem for REQ 3.1e, which states that, the device
should be waterproof. To test if the vents were required, we ran the Übercaster for 32 hours straight and
felt for how hot it got. The components did not get hot to the touch, so it was determined that vents would
be surplus to the design.
7.6 Übercaster Current Draw Test
We wanted the device to last 4 hours at least when it was actively broadcasting. We tested the current
draw of the board when it actively broadcasting. Figure 7.2. In a 10-minute test period, the current draw
ranged from 467mA to 584mA when broadcasting and a current draw of 380mA – 400mA when it was
on IDLE setting.
49
Figure 7-5: The Current Draw Test Setup
7.7 FCC Regulation Test
We realized that if our product were going to go on market, it would need to pass a rigorous FCC test.
Radiation is a issue that is often times overlooked, since we are transmitting via high radio frequencies, it
is very important that our product doesn’t harm anyone. We want to be good stewards and be transparent
about the potential harm, if it ever imposed any. In 15.245 of the FCC guideline, it says that products
using bands 2435-2465 MHz need to have the following specifications. Table 7.3 shows the limits of the
harmonic and fundamental field strengths.
Table 7-4: FCC regulation test results
Fundamental frequency
(MHz)
Field strength of fundamental
(millivolts/meter)
Field strength of harmonics
(millivolts/meter)
2435-2465 500 1.6
Since we will be frequency hopping, if needed, to minimize congestion, we will also need to meet the
requirements of the following statement. “Frequency hopping systems in the 2400-2483.5 MHz band
shall use at least 15 channels. The average time of occupancy on any channel shall not be greater than 0.4
seconds within a period of 0.4 seconds multiplied by the number of hopping channels employed.
50
Frequency hopping systems may avoid or suppress transmissions on a particular hopping frequency
provided that a minimum of 15 channels are used.”
We realized that the chip used in the USB Wi-Fi module (Realtek RTL8188CUS) was already approved
by the FCCxiv. This resulted in a safe promise that the FCC requirements were met and that we can safely
inform the users that the Übercaster is FCC approved.
51
8 Business Plan
8.1 Vision and Mission Statement
Übercaster’s vision is to create a product that is simple, distinctive, and reliable. The product should be
something that everyone can use and love. We want to personalize broadcasting anywhere. We want to
build a product that is efficient in terms of production. We want to research and find innovative ways to
improve our product further, so that it may perform better and drive the price down. We want to
implement the latest technology such as the new 802.11ac protocol. We want Übercaster to be an
experience, not just a product. We respect greatly the designs of Dieter Rams and Jon Ives. Our design
philosophy is not simplicity just for the sake of simplicity, but functional simplicity.
8.2 Industry Profile and Overview
8.2.1 Competition
Our competitions to Übercaster can be broken down in two categories: WiFi/4G broadcast and FM
broadcast. WiFi/4G broadcast competitions are a company called LiveStream, Ustream, and Spreaker.
LiveStream broadcasts in Real-time HD videos to the Internet via WiFI, 4G, and the Ethernet. Ustream
and Spreaker are alike in the sense that it allows users to easily broadcast themselves using the Internet
with a Computer or an iPhone, however both of them depended on an Internet service provider or a
carrier. The distinct feature about the Übercaster is that it is a Hotspot. We broadcast locally, not to the
Internet. FM broadcast competitions are Vox Network and Williams Sound. Vox Network distributes FM
receiver and transmitter devices to tour guide industries and Williams Sound develops and distributes FM
systems worldwide.
8.2.2 Limitations and Regulations
Since Übercaster allows anyone to stream any audio signal, there is a chance that Übercaster might run
into problems concerning the issue of copyright. YouTube, Napster, and Kazaa had to shutdownxv or had
to pay reparationsxvi for the copyright infringement to recording and media companies. Since this is
broadcasting, if we wanted to market the product in the US or in Europe, we would have to pass a
rigorous test by FCC or BEREC. Radiation is a issue that is often times overlooked, since we are
transmitting via high radio frequencies, it is very important that our product doesn’t harm anyone. In
15.245 of the FCC guideline, it says that products using bands 2435-2465 MHz need to have the
following specific fundamental and resonance field strength.
52
8.2.3 Trends in Society
The current trend in society is to have a product that is highly functional, but also looks beautiful. Apple
is a master of this. They have very innovative products that are intuitive, beautiful, and powerful. Sharing
one’s individuality seems to be more prominent more than ever through YouTube, Facebook, Kickstarter.
Now anyone can broadcast his or her individuality without the dependence of an infrastructure.
8.2.4 The Cost of Entry
We believe that the cost of entry is $1,106,900 assuming that 10,000 units of Übercasters are sold. The
detailed analysis and report is found in section 8.8. If we ever pursue to market the product, we are hoping
to receive funding from StartGarden and let distribution and manufacturing companies take stake/equity
in the company in exchange for reduced costs.
8.2.5 Necessities for Success
Our company is relying on the fact that people want to personally broadcast information and that the
smartphone sales increases more and more. Organizations such as churches and museums must be willing
to try a different way of broadcasting than FM transmitters.
8.2.6 Projections for the Future
After TwistThink, a design company in Holland MI, showed interest in our idea, we realized that there
could be partnership in the future. I proposed to Mr. Ryne DeBoer, new business developer at
TwistThink, whether they would be interested in taking equity if we do start a company. Übercaster
would then get help from their engineers and designers. We also had correspondence and meetings with
Rick DeVos and the StartGarden team to share our vision. We had very positive response and our team
believes that we can get initial seed funding to kickstart our development. We also got the approval to test
the Übercaster during ArtPrize. Our goal is to stay lean as possible and grow organically as much as
possible. We are designing our product so that museums, street musicians, and tour guides can use it. We
are proud to say we are in contact with at least one from each market: The GRAM, The Busking Project,
and a local tour guide company in Grand Rapids. Our company plans to further improve the initial design.
Since our product is a niche market, it would be economically more beneficial to go international initially.
We want to implement the newer WiFi module that uses the 802.11ac protocol. We want to have a chat
function so that clients can chat with each other.
53
8.3 Business Strategy
8.3.1 SWOT Analysis
Strength: Unique. There are products with the similar philosophy to change the way people broadcast,
but our method is unique in the sense that it is service provider independent. Übercaster is focused on the
near field range, not the world.
Weakness: no capital, relatively low tech. The technologies that are used in the Übercaster is low tech.
The Übercaster can be built relatively easily. Also with the increasing performance of the smartphone, it
might be possible to eliminate the hardware aspect of the Übercaster.
Opportunities: Work with World Federation of Tour Guides Association, ArtPrize, GRAM, and The
Busking Project, Witte Travel and Tour to promote the use of Übercaster. Partner with manufacturing
companies in China.
Threats: Large designers implement our function in smartphones. China develops a lower cost version of
our product.
8.4 Marketing Strategy
8.4.1 Target Customers
From our market research, we have determined there is a large potential for customers in Tour guide
systems for museums, streaming live music at music venues, translations or audio enhancements for
churches, and live music streaming for street musicians to receive a larger audience. These are the
markets we shall mainly focus on but there are others that shall benefit from our product as well.
8.4.1.1 Tour Guides
After talking to the tour guide director of Witte Travel and Tour, Mr. Nate Barendse, he said that it would
save them quite a bit of cost by not purchasing a FM transmitter and receiver set said they just paid $4000
for 1 transmitter and 50 receivers system. They are a pain to manage (battery change, lost, stolen, broken
devices) Übercaster can be used in loud and quiet places, which allows for a wider variety of applications
for tours. Tours can be given in quiet museums or in city streets with loud ambient noise.
Some tour guides use FM transmitters and receivers to handle the situation. However, this can cost
anywhere from $2,000 to $6,000xvii as demonstrated by Witte Travel and Tour. Übercaster’s goal is to
have one device that transmits and audiences can use their smartphone to listen in. Tourists can stream the
54
content directly to their smartphone whether it is live or recorded. This application received a very
positive response from the local tour guide company.
8.4.1.2 Public Events
For large audiences, we are developing a larger scale version of Übercaster that shall allow several
hundred listeners to connect and stream the audio live. This shall mainly be for large concerts in which
people want to hear the musicians without ambient noise. We met with met with Rick DeVos and rest of
his team at StartGarden to present our product. We got the permission to use our product during ArtPrize
when we felt that Übercaster was ready to be tested. The team also suggested that we submit our project
on StartGarden.
8.4.1.3 Street Musicians
Street musicians can simply plug their instruments into Übercaster and broadcast to audiences within a
450 ft. radius like shoppers or bystanders who want to hear without ambient noise. Nick Broad, the
founder of the Busking Project, has been in contact with us quite a bit. He has connections to 4000 street
musicians worldwide. He connected me with few well-known street musicians such as Dave Crowe of
HeyMoonShaker and Bryson Andres. We shared our idea and vision with him and both of them had a
very positive response saying they would definitely be interested in getting one whenever they are
available.
8.4.1.1 Museums
Museums really use to amplify the interaction between the tourists. Currently a lot of museums use VOX
system, which is a looping playback player. However the cost of these devices are once again irrationally
high and also it is hard to manage. Also It often times disappoints the tourists because they must pay a
high fee to rent out these devices. By having multiple Übercaster through a museum, tourists can easily
access the device and stream audio or rich media content.
8.4.2 Customer Benefits
In general, customers benefit from the following: saves cost by using less hardware than previously used
and broadcasts becomes more personal. Übercaster allows for social broadcasting. In the future, we will
include features like chat and website function built into the Übercaster.
8.4.3 Market Size
There are 17,500 museumsxviii in the U.S, thousands of street musicians, and 95,000 churchesxix in the U.S
as well. We contacted TheBuskingProject.com to ask about the approximate numbers of street musicians
55
in the U.S. We got a message back saying that the number of total street musicians is unknown. From the
email I received from Nick Broad, who is the founder of The Busking Project, he said that his website has
4000 registered street musicians around the world. There are approximately 200,000 individual tour
guides across 70 different countriesxx. We imposed a hypothetical question to both The Busking Project
and the World Federation of Tour Guides Association by asking for their estimation of people who would
be interested in this product. Busking Project said about 2000 and from the 200,000 individual tour guides
from their database, they expected at least 8000 would be interested in using our device. When we talked
to Witte Travel and Tour, the tour guide director ‘purchased’ 20 Übercasters on the condition it did what
was pitched by our team.
8.4.4 Logo Display
Each team member designed their own logo and out of each, one shall be chosen for use for each of our
implementations of Übercaster including the main screen on the app.
8.4.5 Pricing
Based on our estimates from the market size, initially we plan to sell 10,000 units. In order to break even,
we need to sell at a price point of $130. The calculation of the price can be found in the financial
statement section.
8.4.6 Advertising
Our company shall use Google AdWords to set up campaigns. By using keywords such as “Wireless
audio transmitter” or “personal broadcaster,” we can reach on a monthly average basis of 1.3 million
users. We shall ask bloggers and tech writers to do a story and review of Übercaster such as on
TechCrunch, The Next Web, and Gizmodo. Informally we shall an AMA on Reddit and start a
KickStarter campaigns.
8.4.7 Production
We will make use of the one stop manufacturing company, Arcadia Concepts. They gave us a quote of
$84.00 per device if we made around 10,000 units. By using labor in China, we can reduce the costs
drastically.
8.4.8 Distribution
We have been talking to a company called Williams Sound. Williams Sound is an international distributor
and producer in FM transmitter and receiver devices. Williams Sound has market presence, so it would be
a great partnership to manufacture the devices in China and use Williams Sound as a channel. We made a
56
very convincing case suggesting that the Übercaster can really revolutionize what it means to broadcast
locally.
8.5 Financial Analysis
8.5.1 Forecasting
The United States economy is still recovering from the recession. As a result, early adopters and investors
are hesitant to take up new products for fear of losing valuable capital. By the time Übercaster is ready to
roll out the first product, however, the market conditions shall be better and more favorable to new
products and ideas.
8.5.2 Key Assumptions
Rather than setting up a ‘full’ business, we thought that it would be convenient as well as economical to
partner with two major companies: Arcadia Concepts and Williams Sound. Since the production and
distribution channels of the companies are well setup, it would be, initially, the best way to start our
business. We start as a fabless small company. We will make use of consultants to save costs in the initial
years. We are assuming that we sell at least 10,000 units in the first year based on our market size study.
We are assuming that we can partner with Arcadia Concepts and Williams Sound. We assumed that we
would have a steady annual sales growth of 30%, which is a typical growth rate for a small successful
company in the initial years. We are also assuming that our revenue is constant throughout each month.
We will base our fixed and variable costs on producing 10,000 units. We are assuming that we will have
the minimum capital to start our business.
8.5.3 Financial Statement
Based on costs shown below, the financial statement has been devised in Table 8-1.
Variable Costs Cost Justification Prototyping $1,500 5 custom designs @ $300 Consulting Engineers $20,000 200 hours at $100/hr Attorneys and Legal as Consultants $8,000 $200/hr*40hr = $8000 Accountants and Financial on Consultants
$6,500 $165/hr*40hr = $6500
PCB and Enclosure production/Assembly Packaging
$840,000 Arcadia Conceptsxxi
57
Shipping Costxxii $125,000 $12.50*10,000=$125,000 Total $1,001,000
Fixed Costs Cost
Insurance $5,000
Website $10,000xxiii
Total $15,000
Overheadxxiv Cost Justification
Entrepreneur $65,000
Engineer, CEO, Marketer Research and Development $20,000 Extraneous Costs to cover further development of the product Fringe Benefits $5,900
Total $90,900
Grand Total $1,106,900
Table 8-1:Übercaster Financial Statement
Übercaster
Pro-‐Forma Statement of Income
Year 1
Year 2
Year 3
Sales revenue 1,300,000
1,690,000
2,197,000 Variable Cost of Goods Sold 1,001,000
1,301,300
1,691,690
Fixed Cost of Goods Sold -‐
-‐
-‐ Depreciation -‐
-‐
-‐
Gross Margin 299,000
388,700
505,310 Variable Operating Costs 15,000
15,000
15,000
58
Fixed Operating Costs 90,900
90,900
90,900 Operating Income 193,100
282,800
399,410
Interest Expense -‐
-‐
-‐ Income Before Tax 193,100
282,800
399,410
Income tax (40%) 77,240
113,120
159,764 Net Income After Tax 115,860
169,680
239,646
Übercaster
Pro-‐Forma Statement of Cash Flows
Year 1
Year 2
Year 3
Beginning Cash Balance -‐
115,860
285,540 Net Income After Tax 115,860
169,680
239,646
Depreciation expense -‐
-‐
-‐ Invested Capital (Equity) -‐
-‐
-‐
Increase (decrease) in borrowed funds -‐
-‐
-‐
Equipment Purchases -‐
-‐
-‐ Ending Cash Balance 115,860
285,540
525,186
8.5.4 Break-Even, Revenue, and Profit Analysis
If we are able to sell 10,000 units at $130 then our revenue shall be $1.3 Million in our initial year, which
means we will have a profit of $115,860 after tax. If we grow at the assumed rate, then our cash balance
will increase 8% in the first year and then 19% in the 2nd year. The analysis is shown in Table 8-2.
Table 8-2: Analysis and Justification of Break-Even, Revenue, and Profit
Analysis Justification
Break-Even Unit 8515 Units
Revenue $1,300,000
Total Costs $1,106,900
Profit after 40%Ttax $115,860
59
9 Project Management Designing and producing the Übercaster prototype depended on the scheduling and structure of tasks
distributed among the team members. Management of our project was one of the most important aspects
in moving forward with development. A lack of management is an ignorance of knowing how team
members function and work together. The main side effect is a lack of communication which leads to
slow progress and poor team member relationships. Our team has been through the ups and downs of
these project management effects but has come out gaining valuable experience in learning how to work
on a large project with a diverse team of engineers. We have done our best to overcome these struggles
and to finish our project with something we are proud of.
9.1 Team Organization
Through the use of online applications like Trello (Fig. 10.3) and Smartsheet (Fig. 10.2), we have
organized and assigned tasks to be completed. We have also set up means of communication with each
other in order to evaluate how each member is progressing with their tasks and redistribute the workload
if needed. Organizing the team means setting the workload to be consistent and smooth. To do this, each
team member has been assigned responsibilities corresponding to their strengths.
9.1.1 Division of Work
9.1.1.1 Bob
Because of his experience in iPhone app development, Bob has taken on the client and admin aspects of
the smart phone applications on the software side of Übercaster. He has also had experience in designing
PCB boards in a past internship, which shall help in designing our PCB board with the components tested
with the development boards.
9.1.1.2 Nate
For most of the year, Nate took on the role of project manager. Having this role means assigning and
scheduling tasks, planning the meeting times, and making sure each team member keeps the others
accountable for getting their tasks finished. Because this role was sometimes put on the back burner due
to a busy last half of the semester, KJ took over the role. Nate has also contributed a major role to the
Android app development.
60
9.1.1.3 Afa
Afa has been assigned all the mechanical aspects of Übercaster since he is the only mechanical engineer
in the group. He shall be designing the enclosure for the PCB which includes finding the best materials to
use and optimizing the space within the device. Afa is also in charge of the power management and try to
minimize its power consumption and allow a decent battery life.
9.1.1.4 KJ
The concept developer was assigned to KJ. This means he was responsible for making Übercaster come
alive. He works with the embedded software and hardware of Übercaster. He also is in charge of the
network protocol making sure the WiFi network can be created and that audio can be broadcasted. He is
the team’s researcher for finding the best development boards to accomplish our goal and understanding
how the transmission from client to host shall work with Übercaster. KJ also manages the budget and is in
charge of analyzing our business and market capabilities.
9.1.2 Team Advisors and Support
The team’s primary advisor is Professor VanderLeest from Calvin College's Engineering Department.
Also in the College’s Engineering Department is Professor Kim who has helped a great deal with
showing us the steps we should take for making a proof of concept and moving on from there. Prof. Kim
has also sponsored us by providing one of our development boards for testing the proof of concept.
Professor Medema from the Business Department teaches the concurrent Business Aspects for Engineers
course and has helped a great deal with our business plan. Bob DeKraker, the Department Lab Manager
has helped us order the parts we need.
The team also set up meetings with Twisthink and Start Garden to talk about the feasibility of our project
and possibly turning it into a business. Both meetings were fruitful and we received great feedback on our
device. They liked what they saw and shared some ideas on what the direction of our project should take
and what kind of markets we should be tapping into.
For the Android development, we received guidance from Stephen Clemenger who is a fellow student
that has had experience with Android app development. He helped debug he issues we were having the
RTP stream and recognized the problem of the android.net.rtp library not having the necessary codec
needed to decode the audio signal.
61
9.1.3 Team Meetings
The team puts in an effort to meet at least once a week outside of class go over upcoming deadlines and
make sure everyone is on track with their assignments. We try to keep each other accountable and help
out when another team member is overloaded with assignments. If tasks are finished early, we take on
more responsibilities to lighten the load later in the year.
9.1.4 File Management
In order to keep our assignments and files organized, we set up a Dropbox folder which acts as a normal
folder on each of our individual computers but all files in that folder is shared with the other teammates
(Figure 9-1). Our Dropbox folder is divided into sub-folders for hardware, software, mechanical,
business, and anything that is important and large enough that needs organization. We also use Google
drive to make and store block diagrams and other designs using Lucidchart.
Figure 9-1: The top level organization of our file sharing structure utilizing Dropbox.
62
9.2 Schedule
Early in the project we created a Work Breakdown Schedule (WBS) in which we planned the tasks for the
whole year deciding what needed to be done and when it should be completed. Over the course of the
year, it has been edited to reflect a better understanding of certain tasks as well as design decisions. It can
be downloaded and viewed herexxv. In order to visualize what tasks need to be done and better prioritize
them, we use the website https://trello.com (Figure 9-2) and assign tasks to members of the team and
estimate times for them to be finished. Trello only shows upcoming tasks. For a look tasks for the whole
year, we turn to our Gantt chart which is compiled on https://smartsheet.com (Figure 9-3).
Figure 9-2: Organizing and scheduling tasks through Smartsheet.
9.2.1 Schedule Management
Using tools like Trello and Smartsheet, the project manager can easily visualize what needs to get done
and communicate with the team members so that each member knows what still needs to be done. An
example of this website can be seen in Figure 9-2. Every week, Nate reminds the team what needs to be
completed and makes sure everyone does his or her part. The schedule is important to maintain in order to
stay on track with design. We must also stay on schedule to take into account any unforeseen setbacks
and be able to adjust for them.
63
9.2.2 Critical Path
Übercaster has four different areas which have their own critical paths: Mechanical, Hardware, Software,
and Business. There is a necessary sequence of events inside and outside these four areas since tasks in
some of these depend on tasks in others. For example, designing the enclosure requires a significant
amount of knowledge of the development board’s dimensions so it is critical to obtain the necessary
development board before the enclosure design is made. Dependencies like this are accounted for in our
Gantt chart and have ultimately shaped our critical path (Figure 9-4). We anticipate unexpected deviations
from our plan which shall prevent us from making our later version of Übercaster (Figure 9-5) but our
goal is to build and test our created design by Senior Design night. Figure 10.6 below shows these major
tasks and when we expect to be finished with them.
Figure 9-3: Example of how we utilize trello.com
64
Figure 9-4: Desired Critical Path From First Semester
Übercaster v0.1 Übercaster v1.0 Übercaster v2.0
Have Dev. Board be able to: Include v0.1 and: Include v1.0 but:
- Broadcast WiFi network - Make enclosure for dev. Board - Have designed PCB
- Play MP3 - have the board battery powered - Have enclosure for PCB
- Play back audio from mic - Have updated Smartphone apps. - Have desired functionality
- Broadcast audio on network
Have Smartphones be able to:
Have Linux Machine be able to: - Download our app.
- Connect to network - Connect to network
- Stream audio from network. - Stream audio from network.
Figure 9-5: Desired versions of Übercaster to be achieved by end of year.
65
9.2.3 End of the Year Schedule Assessment
The critical path in Fig. 9-4 shows that many of the tasks were completed far behind schedule. This
proves that when working on a project like this, things do not often get completed on time and is
important to schedule a buffer time near the end of the project. For some of the tasks, we were able to
achieve an appropriate buffer time but other tasks were nearly left uncompleted. Another way to see the
effort put into completing the tasks on time is to look at the hours from the entire year in Table 9-1. The
last week before the project needed to be finished was when the team members put in the most amounts
of hours from the entire year.
The team ended the first semester with a total of 178 hours and was far behind schedule. Since the proof
of concept was not completed at the end of the semester as was planned, the team estimated that they
were around 35% finished with the project. Thanks to KJ, Übercaster v0.1 (from Figure 9-5) was born in
late January in the year 2013 and the team could catch up to their desired schedule.
Near the start of the second semester, the team estimated that the project was about 500 hours from
completion judging from the schedule of tasks (WBS) and estimated work completion from first semester.
This leaves 125 hours per person which was thought to leave plenty of buffer room. From Table 9-1, the
team’s estimation was very close with an actual team total of 475.5 hours (average of 119 hours each) in
the second semester.
Judging from the correlation of the estimated to the actual completion time, the team had we well
scheduled project with all the tasks lay out for the whole year. Knowing what tasks to work on does not a
mean they will get done on time, however. From the critical path in Figure 9-4, it is obvious that the team
struggled to finish tasks on time; it was only because of smart scheduling that they did not fall hopelessly
behind.
Table 9-1: Summary of hours for entire year.
Week Afa Bob KJ Nate Team Date 1 2 1 5 2.5 10.5 9/16-‐9/22 2 2 2.5 3 2 9.5 9/23-‐9/29 3 2 0.5 0 1.5 4 9/30-‐10/6 4 1.25 0 0 0 1.25 10/7-‐10/13 5 6.25 4.5 9.5 3.5 23.75 10/14-‐10/20 6 5 3 9 0 17 10/21-‐10/27 7 2.25 3.5 7 2 14.75 10/28-‐11/3 8 2 4.33 6 7 19.33 11/4-‐11/10
66
9 6.5 7.25 1.5 2 17.25 11/11-‐11/17 10 0 4.5 0 4 8.5 11/18-‐11/24 11 9 8 3 8 28 11/25-‐12/1 12 6 4 6 8 24 12/2-‐12/8 13 0 2 0 0 2 12/9-‐12/15
Sem. Total 44.25 45.08 50 40.5 179.83
Christmas Break 5 0 20 15 40 12/15-‐1/2
Interim 15 6 40 0 61 1/3-‐1/26 1 0 3 0 12.5 15.5 1/27-‐2/2 2 6 2.5 10 12.5 31 2/3-‐2/9 3 4 6.5 4 6 20.5 2/10-‐2/16 4 2 3 2.5 2 9.5 2/17-‐2/23 5 3.5 15 6 5 29.5 2/24-‐3/2 6 3 4 2 4 13 3/3-‐3/9 7 7 5 3 5 20 3/10-‐3/16 8 12 5 3 8 28 3/17-‐3/23 9 2 1 3 7 13 3/24-‐3/30 10 10 7.5 3 5 25.5 3/31-‐4/6 11 8.5 9.5 4 11 33 4/7-‐4/13 12 5 10.5 5 9 29.5 4/14-‐4/20 13 20 4 22 10 56 4/21-‐4/27 14 30 36.5 22 30 118.5 4/28-‐5/4 15 7 10 8 8 33 5/5-‐5/11
Sem. Total 120 123 97.5 135 475.5 Year Total 184.25 174.08 207.5 190.5 756.33
9.3 Operational Budget
The budget for Übercaster is managed by Nate Snippe and is seen below in Table 9-2. The team decided
that a budget of $750 for the whole year was necessary to produce Übercaster. The major spending in the
fall semester included the development board and accessories for initial testing. During the spring
semester, most of our budget went towards three iterations of a 3-D printed enclosure for Übercaster.
After the project was deemed finished, we had a surplus of $125.11.
67
Table 9-2: Operating budget for Übercaster throughout the year.
Date Description Debit Total Used
Remaining Balance
10/25/2012 Beginning Balance $750.00 10/25/2012 Router 30.00 30.00 $720.00 10/31/2012 Batteries and Charger 36.31 66.31 $683.69
11/29/2012 USB WIFI module, dev board, TFT screen, linux sound card, DC power plug 152.94 219.25 $530.75
1/31/2013 Rectangular Header 2.64 221.89 $528.11 2/4/2013 Miniand A10 85.00 306.89 $443.11 2/28/2013 3-D printed enclosure 1.0 90.00 396.89 $353.11 4/12/2013 3-D printed enclosure 2.0 108.00 504.89 $245.11 5/2/2013 3-D printed enclosure 3.0 120.00 624.89 $125.11
68
10 Conclusions
10.1 Accomplishments
We have successfully built a platform for streaming audio. We have chosen a development board to
use, installed a custom operating system on it, used a specialized program to encode audio data form the
board, and stream the data over a WiFi channel. We have successfully received the stream with laptops
and played it with minimal delay.
We have successfully designed and created an enclosure for the development board. Using Calvin’s
3D printer, we have an enclosure to test and revise for future implementations of Übercaster.
We have created apps for both the Android and iOS mobile operating systems. Both apps have a
functional user interface and code to receive the data stream.
10.2 Lessons Learned
This project has taught us many lessons about ourselves, and each other. We have learned how to work as
a team, and have a better understanding of each other’s strengths and weaknesses. We also have learned
that communication is essential for our group to succeed. When we do not communicate, we become very
disorganized and loose in our focus.
In addition, we have learned about how we interact with each other. We have different personalities, and
tend toward certain ideas and beliefs of the scope, the direction, and the individual tasks of the project.
We have learned how to cooperate and compromise on different aspects of the project, and how to better
listen to each other and give feedback.
Our biggest lesson learned is that staying on track with the schedule and keeping each other accountable
for their work is very important. We have fallen behind with poor team management. Recently, Nate has
volunteered to take a more direct role as the manager for the team. What he plans to do has been
mentioned in the sections above.
10.3 Credits and Acknowledgments
Team 10 would like to thank the following people for their contribution to the success of this design
project.
69
• Professor Steven VanderLeest of Calvin College Engineering Department for his professionalism
and commitment to support the team as an advisor.
• Professor Yoon Kim of Calvin College Engineering Department for donating parts for
experimenting and for providing insight into the scope of the project.
• Professor Ned Nielsen of Calvin College Engineering Department for his contribution in
developing production options and cost analysis.
• Glenn Remelts of Hekman Library for his assistance in research.
• Phil Jasperse for his metalwork class.
• Bob DeKraker for placing orders for all senior design teams.
• Our Interns from the Business Department of Calvin College who did market research and talked
to local museums, churches, and performers.
• To Team 03 from class of 2012 for their model of writing a PPFS
70
11 References
http://www.machinist-materials.com/comparison_table_for_plastics.htm
http://www.machinist-materials.com/comparison_table_for_plastics.htm
https://www.olimex.com/Products/Duino/Duinomite/_resources/DuinoMite-UM-1-03.pdf
http://rxwen.blogspot.com/2011/10/stream-audio-via-udp-on-android.html
http://en.wikipedia.org/wiki/Streaming_media
http://en.wikipedia.org/wiki/Multicast
http://jas-hacks.blogspot.com/2012/09/hackberry-wireless-access-point.html
http://ubuntuforums.org/showthread.php?t=1127000
http://ubuntuforums.org/archive/index.php/t-1544946.html
http://www.patheticcomputing.com/?p=134
http://sonnati.wordpress.com/2011/08/30/ffmpeg-%E2%80%93-the-swiss-army-knife-of-internet-
streaming-%E2%80%93-part-iv/
https://www.virag.si/2012/11/streaming-live-webm-video-with-ffmpeg/
http://superuser.com/questions/53957/what-do-alsa-devices-like-hw0-0-mean-how-do-i-figure-out-which-
to-use
http://ffmpeg.org/trac/ffmpeg/wiki/StreamingGuide
http://stackoverflow.com/questions/14150365/how-to-send-receive-rtp-audio-stream-c
http://www.alsa-project.org/main/index.php/FramesPeriods
http://www.cs.odu.edu/~cs778/jmflects/lect8RTPPresenting.html
71
i http://www.centrumsound.com/digi-wave_tour_guide_system.html iihttp://www.netmarketshare.com/report.aspx?qprid=8&qptimeframe=M&qpsp=171&qpch=350&qpmr=100&qpdt=1&qpct=3&qpcustomd=1&qpcid=fw54549&qpf=1 iii http://www.w3.org/Protocols/HTTP/AsImplemented.html iv http://developer.android.com/about/dashboards/index.html v http://stackoverflow.com/questions/1613737/server-to-stream-rtsp-to-android vi https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A13-OLinuXino viihttps://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/resources/A13-Brief.pdf viii http://be.eurocircuits.com/shop/element14/pcbproto.aspx?cadsoft=1&customerid=0&customeremail=&tid=eab8d983-ffe1-5afe-1d74-151bf5b2e631&n=117528e7-cdde-476d-8b79-c3f88b86a680# ix http://batteryuniversity.com/learn/article/whats_the_best_battery
http://www.energizer.com/learning-center/Pages/battery-comparison.aspx
http://www.diffen.com/difference/Li-ion_vs_NiCad
http://en.wikipedia.org/wiki/Lithium-ion_battery
http://en.wikipedia.org/wiki/Nickel%E2%80%93metal_hydride_battery
http://en.wikipedia.org/wiki/Nickel%E2%80%93cadmium_battery ix http://blog.ides.com/plastics_marketplace/2012/01/noryl-gtx-830-hips-nylon-petg-pbt-tpe-pet-ldpe-pp-plastic-materials-for-sale.html ix http://www.ides.com/resinpricing/Secondary.aspx x http://blog.ides.com/plastics_marketplace/2012/01/noryl-gtx-830-hips-nylon-petg-pbt-tpe-pet-ldpe-pp-plastic-materials-for-sale.html xi http://www.ides.com/resinpricing/Secondary.aspx xii xiii http://www.custompartnet.com/materials/acrylonitrile-butadiene-styrene xiv https://apps.fcc.gov/tcb/GetTcb731Report.do?applicationId=738688&fcc_id=A5LRTL8188CUS xv http://www.pcworld.com/article/91144/article.html xvi http://www.techdirt.com/articles/20090519/1127454934.shtml xvii http://www.centrumsound.com/digi-wave_tour_guide_system.html xviii "WebCite Query Result." WebCite Query Result. American Association of Musueums, 10 July 2012. Web. 01 Dec. 2012. <http://www.webcitation.org/693Qzdy15>. xix "Oddity Software - Databases, Development and Design." U.S. Churches Database. Oddity Software, n.d. Web. 01 Dec. 2012. <http://www.odditysoftware.com/page-datasales38.htm>. xx http://wftga.org/who-we-are/what-wftga xxi http://www.arcadiaconcepts.com/ xxii Shipping Cost = $12.50 * 10,000 (http://www.cypressindustries.com/faq_freight.html)
72
xxiii Estimated cost of annual website maintenance, security and design update. We don’t want to have security failures. Websites are one of the most recurring costs for a small business that is growing. xxiv These values are the national average for the occupation estimated through http://www.salary.com/ xxv https://www.dropbox.com/s/8w69ohoyymqbhhn/Team10.WBS.pod.pod