fmNOW TEAM 1 - Calvin College | Grand Rapids, Michigan · PDF filefmNOW . TEAM 1 . Jordan Schaenzle . Peter Tuuk . ... 9.1.1 FM Radio Reception ... Project Proposal and Feasibility

PROJECT PROPOSAL AND FEASIBILITY STUDY

fmNOW TEAM 1

Jordan Schaenzle Peter Tuuk Job Vranish

Brad Zoodsma Mike Zwagerman

SENIOR DESIGN December 08, 2006

ENGR 339 CALVIN COLLEGE

Abstract The ability to pause, rewind, save, and playback multiple radio stations would be a great addition to any radio. There are many applications in which this technology can be applied such as home stereo systems, car audio players, and even home theater systems. This document goes through the feasibility of designing and constructing such a device.

ii

Contents 1 Introduction ........................................................................................................................................ 1

1.1 Team............................................................................................................................................ 1 1.2 Project.......................................................................................................................................... 2

2 Objectives............................................................................................................................................ 2 2.1 Design Functionality ................................................................................................................... 2 2.2 Educational Opportunities ........................................................................................................... 3 2.3 Design Norms.............................................................................................................................. 3

2.3.1 Justice...................................................................................................................................... 3 2.3.2 Cultural Appropriateness......................................................................................................... 3 2.3.3 Transparency ........................................................................................................................... 3

3 Requirements...................................................................................................................................... 4 3.1 Prototype...................................................................................................................................... 4

3.1.1 Functional................................................................................................................................ 4 3.1.2 Performance ............................................................................................................................ 4 3.1.3 Power....................................................................................................................................... 4 3.1.4 Size.......................................................................................................................................... 4 3.1.5 Weight ..................................................................................................................................... 4 3.1.6 Audio Quality.......................................................................................................................... 5 3.1.7 Cost ......................................................................................................................................... 5 3.1.8 Storage..................................................................................................................................... 5 3.1.9 Interface................................................................................................................................... 5

3.2 Production.................................................................................................................................... 5 3.2.1 Functional................................................................................................................................ 5 3.2.2 Performance ............................................................................................................................ 6 3.2.3 Power....................................................................................................................................... 6 3.2.4 Environmental ......................................................................................................................... 6 3.2.5 Size.......................................................................................................................................... 6 3.2.6 Weight ..................................................................................................................................... 6 3.2.7 Audio Quality.......................................................................................................................... 7 3.2.8 Cost ......................................................................................................................................... 7 3.2.9 Storage..................................................................................................................................... 7 3.2.10 Interface .............................................................................................................................. 7

4 Preliminary Cost Estimates............................................................................................................... 8 4.1 Prototype Preliminary Cost Estimates ......................................................................................... 8 4.2 Production Preliminary Cost Estimates ....................................................................................... 9

5 Design Alternatives .......................................................................................................................... 10 5.1 Microprocessor (Recording and Playing Back the Radio Stream) ............................................ 10

5.1.1 Microprocessor Memory ....................................................................................................... 10 5.1.2 Memory Decision.................................................................................................................. 11 5.1.3 Fully Custom Designed Processor ........................................................................................ 12 5.1.4 Modifying a Supplied Template Processor ........................................................................... 12 5.1.5 Buying off the shelf............................................................................................................... 12 5.1.6 Decision................................................................................................................................. 12 5.1.7 Prototype ............................................................................................................................... 12 5.1.8 Production ............................................................................................................................. 13

5.2 Radio Stream Acquiring and Converting .................................................................................. 13 1.1.2 Design Criteria: ..................................................................................................................... 13 5.2.1 Tuning Alternatives............................................................................................................... 14 5.2.2 Multiple Tuners Alternatives ................................................................................................ 17

iii

5.2.3 Compression.......................................................................................................................... 18 6 Testing ............................................................................................................................................... 20

6.1 Physical...................................................................................................................................... 20 6.2 Functional .................................................................................................................................. 20 6.3 Testing Table ............................................................................................................................. 20

7 Project Management ........................................................................................................................ 21 7.1 Schedule .................................................................................................................................... 21 7.2 Work Breakdown Structure ....................................................................................................... 22 7.3 Team Organization .................................................................................................................... 24 7.4 Methods of Communication ...................................................................................................... 24 7.5 Conflict Resolution.................................................................................................................... 24

8 Research ............................................................................................................................................ 24 8.1 Patents........................................................................................................................................ 24 8.2 Market Study ............................................................................................................................. 25

9 Feasibility .......................................................................................................................................... 26 9.1 Risks .......................................................................................................................................... 26

9.1.1 FM Radio Reception ............................................................................................................. 26 9.1.2 Analysis:................................................................................................................................ 26 9.1.3 Mitigation:............................................................................................................................. 26 9.1.4 Intra-System Interfaces ......................................................................................................... 26 9.1.5 Analysis:................................................................................................................................ 26 9.1.6 Mitigation:............................................................................................................................. 26 9.1.7 Schedule and Deadline Keeping ........................................................................................... 27 9.1.8 Analysis:................................................................................................................................ 27 9.1.9 Mitigation:............................................................................................................................. 27 9.1.10 Content Tagging ............................................................................................................... 27 9.1.11 Analysis: ........................................................................................................................... 27 9.1.12 Mitigation: ........................................................................................................................ 27

9.2 Conclusions ............................................................................................................................... 27 9.2.1 Financial................................................................................................................................ 27 9.2.2 Scope..................................................................................................................................... 27 9.2.3 Design ................................................................................................................................... 27

10 Sources .............................................................................................................................................. 28

iv

Figures

Figure 1 - Senior Design Team 1 Picture...................................................................................................... 1 Figure 2 – Multiple Tuner Design Alternative Block Diagram .................................................................. 14 Figure 3 - Multiplexing Tuner Alternative Block Diagram........................................................................ 15 Figure 4 - Complete Sampling Alternative Block Diagram........................................................................ 16

Tables Table 1 Prototype Non-Labor Costs ............................................................................................................. 8 Table 2 Production Labor Costs ................................................................................................................... 9 Table 3 Production Non-Labor Costs ........................................................................................................... 9 Table 4 Production Cost Summary ............................................................................................................... 9 Table 5 Buffer Memory Alternatives.......................................................................................................... 11 Table 6 - Prototype Microprocessor Alternatives ....................................................................................... 12 Table 7 - Production Microprocessor Alternatives ..................................................................................... 13 Table 8 Solution Implementation Alternatives ........................................................................................... 16 Table 9 Tuner Implementation Alternatives ............................................................................................... 17 Table 10 ADC Alternatives ........................................................................................................................ 18 Table 11 ADC Design Matrix..................................................................................................................... 18 Table 12 - MP3 - A/D Desision Matrix ...................................................................................................... 19 Table 13 Testing Procedure ........................................................................................................................ 20

Equations Equation 1 ................................................................................................................................................... 11 Equation 2 ................................................................................................................................................... 11

v

Abbreviations µP Microprocessor AC97 Audio Codec 1997 ADC Analog to Digital Converter BOM Bill of Materials DAC Digital to Analog Converter DSP Digital Signal Processor FM Frequency Modulated GPIO General Purpose Input/Output I2C Inter-Integrated Circuit

I2S Inter-Integrated Circuit Sound

kHz Kilohertz MP3 MPEG-1 Audio Layer-3 MPEG Moving Picture Experts Group PCB Printed Circuit Board PCM Pulse Code Modulation PPFS Project Proposal and Feasibility Study OS Operating System Ofcom Office of Communications RBDS Radio Broadcast Data System RDS Radio Data System SBC Single Board Computer SPI Serial Peripheral Interface TBD To Be Determined USB Universal Serial Bus VCR Video Cassette Recorder

vi

1 Introduction Calvin College is a liberal arts college located in Grand Rapids, MI. Founded in 18761 as a seminary for the Christian Reformed Church, Calvin has grown to educate 4,2002 each year students in a wide range of fields. Calvin College’s engineering department offers Accreditation Board for Engineering and Technology (ABET) accredited degrees in Chemical, Civil, Electrical & Computer, and Mechanical Engineering. As part of the Engineering curriculum students must complete the Engineering 339/340 sequence known as Senior Design. Each student, in a group of 4 or 5, studies and designs a solution to a problem or to fill a need. This paper is in fulfillment of the proposal requirement for this class.

1.1 Team Calvin College Senior Design 2006-2007 Team 1, shown in Error! Reference source not found., is composed of five electrical and computer engineering students: Jordan Schaenzle, Peter Tuuk, Job Vranish, Bradley Zoodsma, and Michael Zwagerman.

Figure 1 - Senior Design Team 1 Picture

1 http://www.calvin.edu/about/history.htm 2 http://www.calvin.edu/admin/admissions/profile.htm

1

Jordan Schaenzle is a senior electrical engineering major at Calvin College. Jordan has particular interest in digital design as well as automotive electrical engineering. He spent the summer of 2006 working for Schrader Electronics Ltd, an automotive supplier of Tire Pressure Monitoring Systems. Jordan enjoys playing his guitar, woodworking, and participating in many sports. Peter Tuuk grew up in Grand Rapids, MI, attending Grand Rapids Christian High School. Over the summer of 2006, he interned at Smiths Aerospace in Grand Rapids, MI, working on system testing. Peter is a captain of Calvin’s swim team and Secretary of the Calvin College IEEE Club. Peter enjoys cycling and competing in triathlons. Job Vranish is a senior electrical engineering student at Calvin College. He currently works for Smiths Aerospace as a software developer. He will be getting married to his fiancée after he graduates and hopes to continue his work at Smiths. Job enjoys programming and working with computers any way he can. Brad Zoodsma is a senior electrical engineering student at Calvin College. He is currently working in his third year at Smiths Aerospace in Grand Rapids, MI. He worked on the systems design team where he moderated many peer reviews and ran different tests. Brad enjoys doing hardware design. He enjoys playing many different sports, and working on his car. Michael Zwagerman is a senior electrical engineer at Calvin College. He has spend the last year also working on both firmware and hardware projects as an engineering intern at DornerWorks Ltd, an electrical engineering consulting firm in Grand Rapids Michigan. Before that he worked as an engineering intern at Innotec Group, a Zeeland Michigan based manufacturing company. We will work together to create a device called fmNow.

1.2 Project fmNOW is a TiVO-like product for radio. We have noticed that many times when a person listens to the radio they change stations when a commercial plays. More often than not, when a person switches stations, the song on the next station is in the middle of the song. Moreover, if the song is one that the user enjoys there is no way to “go back in time” to hear the beginning of the song. That’s where our project comes in. Our project is a device that a person can use to listen to, pause, rewind, and save multiple radio stations. The user will be able to switch between multiple radio stations and never miss a second of music, news, sports or any other radio program. The user may be able to transfer the songs from our device to a separate device. This will eliminate the frustration of missing your favorite song, that key play, or any of the information that is so important in today’s world. This paper will detail the results of our feasibility and design analysis over the course of the first semester. We will start by outlining our general objectives for the project. Then we will lay out the requirement for the project completion.

2 Objectives

2.1 Design Functionality This is a list of the minimum objectives we wish to accomplish with this project: fmNOW is a device that a person can use to listen to, pause, rewind, and save content from multiple radio stations. The user will be able to switch between multiple radio stations and list to content broadcast in the past. The user will be able to transfer saved content from fmNOW to external media.

2

2.2 Educational Opportunities This project presents many educational opportunities for us. We will be exposed to firmware design, hardware and software debugging, printed circuit board (PCB) layout, hardware design, testing, teamwork, business finance, and budgeting.

2.3 Design Norms As Christian engineers we have a responsibility to think about the Christian principles and norms that apply to our project.

2.3.1 Justice Justice is one norm that we believe specifically applies to fmNOW. A design is just if it is developed in such a way that its implementation is not unfair to any group of people or any individual. The design must respect the rights of not only it’s users but all of the stakeholders involved. Many problems have come about with the introduction of digital media into our society. These especially center on the new capability of copying and stealing music. One feature we are considering implementing in our device is the capability to export stored audio files from the device onto some form or portable media such as a USB flash drive or a similar product. The intention of this feature is that a user would be able to record an audio clip from the radio and transfer it to their computer. Our concern is that this would enable people to copy and distribute music in a manner that is prohibited by copyright laws. After much consideration, our team has decided that this issue will most likely not be a problem for our product. Our group did some research and found that, in one case, the Supreme Court ruled that Video Cassette Recorder (VCR) manufacturer Sony Corporation would not be held responsible for any copyright violations that were perpetrated using their device3. Our product would not be doing anything materially different than a VCR. Additionally, standard audio cassette recorders have been capable of recording the radio for years. From this precedent our group concluded that our design does not issue injustice.

2.3.2 Cultural Appropriateness Another design norm, which in a way ties into the first, is Cultural Appropriateness. This design norm requires that the product “fits in” to the cultural into which it is introduced. Examining our product, it is clear that fmNOW is culturally appropriate. We live in a time where, elementary-school-age children are learning to operate computers and use portable Motion Picture Experts Group (MPEG) Layer 3 (mp3) players, cell phones, and countless other technical gadgets. Music playing devices are now being utilized in nearly every location throughout our world. They’re in the car, the bathroom, the kitchen, the office, the lawnmower, built into winter hats –you name the place, and someone has probably put a radio there. People in our society love music everywhere they go and fmNOW is designed to bring the enjoyment of music to the next level. Our device will plug into a standard 120V electrical outlet which is accessible in every home that has electricity in the U.S. Once the device is turned on, it can be operated by nearly anyone who can use a DVD player or frequency modulated (FM) radio.

2.3.3 Transparency This also relates to the design norm Transparency. The idea behind transparency is that the user interaction is simple and straightforward. The product should not operate in a manner that does not make sense to a common user. Also included within the transparency norm is reliability. The product should function as it is intended to function, consistent with the products advertisements and the user’s expectations.

3 Sony Corp. v. Universal City Studios, Inc., 464 U.S. 417 (1984).

3

3 Requirements The following is a list of minimum requirements that fmNOW will meet.

3.1 Prototype

3.1.1 Functional

1.1.1.1 The device shall be able to sample FM radio audio data from no less than 2 FM broadcasts simultaneously in stereo quality

1.1.1.2 The device shall allow the user to select any station in the FM band for listening

1.1.1.3 The device shall allow the user to pause (for no less than 5 minutes) and resume, one radio audio stream

1.1.1.4 The device shall allow the user to listen to one radio stream, switch to a second radio stream and rewind up to 5 minutes, the second stream

1.1.1.5 The user shall be able to rewind or fast-forward the active stream at a rate of 10 seconds of recorded time per 1 second of real time

1.1.1.6 fmNOW shall be able to store data onto an onboard memory source

3.1.2 Performance

3.1.3 Power

1.1.1.7 fmNOW shall be powered by an DC power source

3.1.4 Size

1.1.1.8 The device shall be no bigger than a form factor of 1’ x 6” x 8” (W x H x D) COMMENT: The market study showed that maximum dimensions for these types of radios are 18.5 x 14.5 x 14 inches (W x H x D).

3.1.5 Weight

1.1.1.9 The device shall weigh no more than 10 lbs COMMENT: This is so the device is easily moved

4

3.1.6 Audio Quality

1.1.1.10 The device shall minimally be able to store radio streams at a rate of 44.1kHz at 16 bit digital quality providing a net raw digital quality of 172KB/s 4

1.1.1.11 The device shall be able to playback audio streams at 44.1kHz

3.1.7 Cost

1.1.1.12 The prototype shall cost no more than $360

3.1.8 Storage

1.1.1.13 The device shall be able to record up to 5 minutes per station

3.1.9 Interface

1.1.1.14 The user interface shall be reasonably intuitive with controls similar to those of current radios and music listening devices

1.1.1.15 The interface shall allow the user to select an FM broadcast to listen to

1.1.1.16 The interface shall show the current station that is being listened to as well as the other stations being recorded

1.1.1.17 The interface shall be able to show different screens to show different functions

1.1.1.18 If a button shall be considered pushed once it has been engaged, not when it is released. During the period when the button is held down, pushing another button will not do anything

1.1.1.19 A button push shall cause a noise to indicate to the user that it has been pushed

1.1.1.20 The interface shall allow the user to pause, resume, or rewind an active broadcast

1.1.1.21 The interface shall allow the user to pause, resume, rewind, or forward a recorded broadcast

1.1.1.22 The interface shall allow the user to switch from a paused broadcast to any another broadcast and vice-versa

1.1.1.23 The interface shall allow the user to turn fmNOW on and off

1.1.1.24 fmNOW shall have a light that signals to the user if the unit is on or not

3.2 Production

3.2.1 Functional

1.1.1.25 The device shall be able to sample FM radio audio data from no less than 3 FM broadcasts simultaneously in stereo quality

4 44100 samples/s × 2 Bytes /sample × 2. channels = 172 KB/s

5

1.1.1.26 The device shall allow the user to select any station in the FM band for listening

1.1.1.27 The device shall allow the user to preset 4 stations and switch between them

1.1.1.28 The device shall allow the user to pause (for no less than 30 minutes) and resume, one radio audio stream

1.1.1.29 The device shall allow the user to listen to one radio stream, switch to a second radio stream and rewind up to 30 minutes, the second stream

1.1.1.30 The user shall be able to rewind or fast-forward the active stream at a 2x speed by pushing the rewind or fast forward button. If the user pushes the rewind or fast forward a second time the device will rewind or fast forward at a rate of 5x speed. If the user pushes the rewind or fast forward a third time the device will rewind or fast forward at a rate of 20x speed

1.1.1.31 fmNOW shall be able to transfer stored files to another source using an external memory source such as USB, Compact Flash, Secure Digital, or the like

3.2.2 Performance

3.2.3 Power

1.1.1.32 fmNOW will be powered by a DC power source

1.1.1.33 fmNOW will have maximum power dissipation of 20Watts COMMENT: We are trying to minimize cost; power is not our focus

3.2.4 Environmental

1.1.1.34 Our device shall operate in the humidity range of 0 to 80% non-condensing

1.1.1.35 fmNOW shall operate at a temperature range of 0ºC to 70ºC

1.1.1.36 fmNOW shall be able to withstand a vibration of 9.8 m/s2 at a frequency of 10Hz

3.2.5 Size

1.1.1.37 The device shall be no bigger than a form factor of 1’ x 6” x 8” (W x H x D) COMMENT: The market study showed that maximum dimensions for these types of radios are 18.5 x 14.5 x 14 inches (W x H x D).

3.2.6 Weight

1.1.1.38 The device shall weigh no more than 20 lbs COMMENT: This is so the device is easily moved.

6

3.2.7 Audio Quality

1.1.1.39 The device will minimally be able to store radio streams at a rate of 44.1kHz at 16 bit digital quality providing a net raw digital quality of 172KB/s 5

1.1.1.40 The device shall be able to playback audio streams at 44.1kHz

3.2.8 Cost

1.1.1.41 The production can cost no more than $28 bill of materials (BOM) cost

3.2.9 Storage

1.1.1.42 The device shall be able to record up to 40 minutes per station

3.2.10 Interface

1.1.1.43 The user interface shall be maximally intuitive with controls similar to those of current radios and music listening devices

1.1.1.44 The interface shall allow the user to select an FM broadcast to listen to

1.1.1.45 The interface shall show the current station that is being listened to as well as the other stations being recorded

1.1.1.46 The interface shall be able to show different screens to show different functions

1.1.1.47 If a button shall be considered pushed once it has been engaged, not when it is released During the period when the button is held down, pushing another button will not do anything

1.1.1.48 A button push shall cause a noise to indicate to the user that it has been pushed

1.1.1.49 The interface shall allow the user to pause, resume, or rewind an active broadcast

1.1.1.50 The interface shall allow the user to pause, resume, rewind, or forward a recorded broadcast

1.1.1.51 The interface shall allow the user to switch from a paused broadcast to any another broadcast and vice-versa

1.1.1.52 The interface shall allow the user to turn fmNOW on and off

1.1.1.53 fmNOW will have a light that signals to the user if the unit is on or not

5 44100 samples/s × 2 Bytes /sample × 2. channels = 172 KB/s

7

4 Preliminary Cost Estimates

4.1 Prototype Preliminary Cost Estimates Currently fmNOW forecasts their preliminary prototype non-labor cost to be $126.90 with reference to Table 1 Prototype Non-Labor Costs fmNOW has received hardware from Calvin College at no cost. This hardware includes a 3.5” Active TFT LCD, 2 single board computers (SBC) powered by Intel XScale PXA255 and a Strategic Test development board for the SBCs.

Table 1 Prototype Non-Labor Costs

Non-Labor: Item Cost QuantityTotal Cost Estimate

Display $0.00 1 $0.00 Actual Single Board Computer (SBC) $0.00 2 $0.00 Actual SBC Dev Kit $0.00 1 $0.00 Actual Micronas MAS3587F (MP3 Encoder / Decoder &

ADC / DAC) $30.00 5 $150.00 Actual Silicon Laboratories SI4701 (FM Tuner) $17.25 5 $86.25 Actual Misc. Electronic Components (Connectors) $10.00 1 $10.00 Estimate Enclosure $20.00 1 $20.00 Estimate PCB (not populated) $0.00 4 $0.00 Estimate Shipping $30.00 1 $30.00 Estimate

Estimated Total Non-Labor Cost: $296.25

Estimated Total Cost: $296.25

8

4.2 Production Preliminary Cost Estimates fmNOW currently forecasts production models BOM to cost per unit maximally $36.20 The majority of component costs are still estimates +/- 50%at this stage in our design and we suspect that further research will lead to lower component costs in volume. Currently we forecast production volume to be 13,398,000 units. One interesting difference between production models and prototype is the microprocessor (µP) we have not yet decided on a production some of the production chips, but we have chosen example chips and the specifications and cost will be similar to these examples.

Table 2 Production Labor Costs Item Item Cost Quantity Total Cost Labor:

Labor $100.00 1750 $175,000.00 Estimate Estimated Total Labor Cost: $175,000.00

Table 3 Production Non-Labor Costs

Item Estimated Item Cost Quantity Unit Cost

Per Unit Prototype Cost $0.00 1 $0.00 EstimateOptrex T-51379L035J-FW-P-AA LCD $10.62 1 $10.62 Estimate

Micronas MAS3587F (MP3 Encoder / Decoder & ADC / DAC) $3.00 2 $6.00 Estimate

Silicon Laboratories SI4701 (FM Tuner) $3.45 2 $6.90 Actual Microprocessor (Similar to Intel XScale PXA255) $3.00 1 $3.00 EstimateMisc. Electronic Components (Connectors) $2.00 1 $2.00 Estimate64MB SDRAM MT48LC2M32B2TG-5:G or Similar $3.40 1 $3.40 Actual 64MB Flash Memory AT49BV6416C-70CI SL383

or Similar $0.87 1 $0.87 Actual Net Circuit Components: $22.17 PCB (not populated) $1.23 1 $1.23 Actual PCB Assembly $1.78 1 $1.78 Actual Enclosure $0.10 1 $0.10 EstimateProduct Assembly $0.10 1 $0.10 EstimateProduct Packaging $0.10 1 $0.10 EstimateProduct Shipping. $0.10 1 $0.10 Estimate

Estimated Total Non-Labor Cost (Per Unit): $36.20

Table 4 Production Cost Summary Item Item Cost

Estimated Total Non-Labor Cost: $485,048,090.25 Estimated Total Labor Cost: $175,000.00

Estimated Total Cost: $485,223,090.25 Estimated Total Cost (Per Unit): $36.22

9

5 Design Alternatives Derived from our project objectives and requirements above there are three basic tasks that our device needs to perform. They are capturing radio, recording audio data from captured radio, and playing back the recorded audio. We began the design process by brainstorming for potential solutions to the design objectives and requirements, more specifically with regards to the ability of our device to capture radio, record radio audio, and playback audio. We decided these abilities applied to two different aspects of the design. The first part acquires the radio stream and converts it into a format that can be recorded, stored, and played back. The second part controls the playing back and user interface. This two part solution needed to implement some sort of buffering and storage which implies some soft of memory. Practical ways to interface and control memory include a microprocessor (µP) or a complex programmable logic device. This section will cover alternatives for the microprocessor, radio reception, and demodulation TBD

5.1 Microprocessor (Recording and Playing Back the Radio Stream) We next needed to decide if we wanted to buy an off the shelf µP and write firmware for it or if we wanted to buy an FPGA and make our own µP in VHDL. (We could also still write firmware.) We looked closer at our requirements to determine viable alternatives. We wanted our solutions to at a minimum store two audio streams coming in at 44100 Hz and playback a single stream (at the same rate) as well as have enough processing power left over for handling user interfacing and any other required control. it will also minimally need enough memory to store 5 minutes per stream.

5.1.1 Microprocessor Memory To determine the memory size requirement we did some preliminary calculations assuming worst case compressed audio at 44100 Hz, 16 bit quality, 2 input stations for prototype, 3 input stations for production , 12:1 MP3 compression ratio6. 5 minutes of record time for prototype and 40 minutes of record time for production per station. We used Error! Reference source not found. below to calculate the required memory size to be 6.3MB for prototype and 50.5 MB for production.

The prototype has 64 MB of RAM and 32 MB of Flash of which may seem excessive for our operation. This in not the case, however, the intent of a prototype is not to minimize cost or performance to meet your production specifications. The prototype is a proof of concept showing that our project is feasible with the right amount of resources. A prototype is also a platform for experimentation and design improvement. Improving our production design may require the use more memory hefty design alternative or test procedures. The production model will include at least 64 MB of memory as well. This provides Linux a minimum 15MB of memory to handle its variables and processes. We are also looking to value add our solution by increasing the amount of memory. This would directly increase the amount of the stream record time.

6 Miller, Dorian. PDF to MP3 conversion: an alternative method to. 30 July 2003. Department of Computer Science ,University of No. 8 Dec. 2006.

10

5.1.2 Memory Decision Both our prototypes will include both Flash and RAM memory. Flash memory has the main advantage of not being non-volatile and is useful for storing code that we don’t’ want to loose e.g. Linux power up code, operating system code and applications. RAM is advantageous because of its fast bandwidth. Both memory types could be used as the location of our buffered streams. Flash memory has a limited number of writes (1 million) associated with it.7 We have done a preliminary calculation to see how long a Flash device would last in our system. We assume that each station would have its own buffer that wraps around. Each buffer would get erased and re-written every 40 minutes. Using Equation 1 below, we can see that a flash chip would last 76 years.

stweenWriteIntervalBe * clesNumberOfCy FlashLife = Equation 1

Both types of memory also have plenty bandwidth for our 3 station buffering. Flash Memory has a bandwidth of 10MB per second.8 Flash Memory is slightly harder to interface with compared to RAM we need to erase whole blocks in order to re-write data.

Table 5 Buffer Memory Alternatives

Bandwidth Ease of

Implementation Life Expectancy Cost Total Points Goal 20 20 10 20 70 Flash Memory 20 15 10 20 65 RAM 20 20 10 20 70

We decided to use RAM as the main buffering memory only because it slightly easier to implement, otherwise it is comparable.

In deciding the processor specifications we did some preliminary calculations to determine the minimum processor speed. We assumed that a store on the processor would take 10 cycles9; a load on the processor would take 6 cycles10. We assumed we would be storing compressed 44100 Hz audio into a buffer from 2 streams for the prototype solution, 3 streams for the production solution and reading compressed audio from 1 buffer. We found that using Equation 1 the minimum prototype processor speed has to be 1.14MHz and the minimum production prototype speed has to be 1.58Mhz.

erLoad)ClkCyclesP * nsLoadStatio erStoreClkCyclesP * onsStoreStati Second(SamplesPer µP_Speed += Equation 2

The prototype has a 400MHz Intel XScale processor, which may seem excessive for our operation. This in not the case, the intent of a prototype is not to minimize cost or performance or to meet your production specifications. The prototype is a proof of concept showing that our project is feasible with the

7 Flash Memory. Wikepdia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/Flash_memory>. 8 Current Trends in Flash Memory Technology. Ed. Sang Min. School of Computer Science and Engineering. 8 Dec. 2006. 9 Intel XScale® Core Developer's Manual. Jan. 2004. Intel. 8 Dec. 2006. 10 Intel XScale® Core Developer's Manual. Jan. 2004. Intel. 8 Dec. 2006.

11

right amount of resources. A prototype is also a platform for experimentation and design improvement. Improving our production design may require the use more memory hefty design alternative or test procedures The required production clock speed can be easily meet with the prototype or similar processor. The biggest handicap then for the processor will be its ability to run our operating system (OS) along with some sort of GUI for our LCD probably something similar to Qtopia. This will require approximately 100 MIPS.

5.1.3 Fully Custom Designed Processor Making our processor to meet these requirements is advantageous because the material cost is low. We can also tailor design this µP to meet only our specifications. Designing our own µP requires large amounts of design and debugging time. We could also use designs from Engineering 325 class as a basis for the required microprocessor.

5.1.4 Modifying a Supplied Template Processor Supplied microprocessor templates, such as Altera’s Nios microprocessor, present an attractive middle ground. This gives the group the freedom to customize the microprocessor to meet our needs, while not demanding as much design time as designing our own. The Altera Nios processor is available through Calvin College’s Altera Quartus software. However, these microprocessors are not as widely used and therefore open-source resources for this processor are not as common.

5.1.5 Buying off the shelf This sort of µP cannot be tailored to our needs, but often requires all the necessary components for functionality like data protocols: I2C, I2S, AC'97, and SPI. (We can also equip a lot of functionality with our own or preexisting firmware.)

5.1.6 Decision

5.1.7 Prototype We decided that buying an off the shelf processor would be best for our prototype. It has faster implementation and it provides functional confidence in our prototype because an off the shelf part has been thoroughly tested and has been used in working implementations. An off the shelf part would also allow us to potentially load existing and even free firmware. We have chosen to use an Intel XScale PXA255 µP chip in our prototype design because this is a popular and powerful µP for embedded solutions that is available to us at no cost through Calvin College. It provides substantial General Purpose Input/Output (GPIO) pins. We have available free Linux firmware and we acquired the chip on a single board computer (SBC) with an evaluation and development environment from Calvin College.

Table 6 - Prototype Microprocessor Alternatives Prototype Microprocessor Alternatives

Cost

Time to

Design

Availability of Open Source

Resources ReliabilityExpansion

Ease Performance Total Score

Goal 20 40 10 5 5 20 100

12

Off-The-Shelf 20 40 10 5 1 20 96 Template (Nios) 20 28 3 4 5 14 74

5.1.8 Production We decided that an off the shelf processor would be best for production as well due to its inexpensive volume price and relative reliability that has been proven in industry. We are at this time still determining exactly which processor we will be using in production but it will incorporate similar features to the µP we are using in the prototype and meet the requirements mentioned above. Open-source availability and design time are not as important in production as in prototype. On the other hand part cost and reliability are more important.

Table 7 - Production Microprocessor Alternatives Production Microprocessor Alternatives

Cost

Time to

Design

Availability of Open Source

Resources ReliabilityExpansion

Ease Performance Total Score

Goal 40 5 0 25 10 20 100 Off-The-Shelf 32 3.5 0 25 2 20 82.5 Template (Nios) 16 3.5 0 20 10 14 63.5

5.2 Radio Stream Acquiring and Converting We have a solution to for recording and playback of a radio stream. However, the radio stream

needs to be acquired and converted into a form usable by the the microprocessor. In this section we show our design decisions and our final solution for radio stream acquisition and conversion.

1.1.2 Design Criteria: We evaluated our design alternatives for radio acquisition and conversion on the basis of four

design criteria: Design Time, Flexibility, Cost, and Risk. A description of each is given below. Design Time:

This is a measure of how much design time we estimate will be required to implement a particular alternative for our system. This includes time required for research, design, implementation, testing, or any other development time needed to implement the alternative as well as any extra development time that might be added to a separate component of our system as a result of choosing this alternative. This does not include design time we may have already spent exploring an alternative. We measure design time in man-hours. Flexibility:

13

This is a measure of how much design time we estimate would be saved, for a particular alternative (relative a hypothetical base alternative that only fulfills the minimum requirements), if we chose to implement enhancements or features to our production model in the future. This is a very rough estimate as we do not know what future enhancements might be made and as such this criterion is not heavily weighted. However, future enhancements to our device will almost certainly be necessary to remain competitive, and consequently we include it as a criterion. Cost:

This is the cost for the alternative 13,398,000. We did not include the cost for small volumes as a design criterion as this will only affect the prototype cost (which has a fixed budget) and as long as we meet the budget, the prototype component costs are irrelevant. Risk:

This is a measure of how uncertain we are of our design time estimate. We quantify this as our estimated variance of a beta distribution of our estimated design time. For a rough estimate we use the formula [(worst case time – best case time) / 6]^2. Where best case time is the time at which we have a 1% chance of completing the alternative. The worst case time is the time at which we have a 99% chance of completing the alternative. PERT charts use this method for their time estimates11.

5.2.1 Tuning Alternatives Radio capture involves taking radio audio information from the FM airwaves and presenting it in a format usable by the microprocessor Solutions for Radio Capture: We have come up with three basic approaches to our FM radio capturing; which are the following:

5.2.1.1 Multiple Tuners

This alternative uses a single tuner for each station that needs to be sampled. Each 'tuner' would have to be controllable by the microprocessor. A block diagram of this alternative is show in Figure 2 below. (this only shows two tuners and A/D converters, the production model will have three)

Tuner

Tuner

A/D

A/D

SBC

Speaker

Figure 2 – Multiple Tuner Design Alternative Block Diagram

11 PERT. Internet Center for Management and Business Admi. 8 Dec. 2006 <http://www.netmba.com/operations/project/pert/>.

14

Each tuner would aquire the FM off the airwaves, and pass analog audio to A/D converts. The tuners would be controlled by the processor. The A/D converters would convert the analog audio to a digital form for the processor. FM tuners are widely used and well understood and as such there is a good deal of documentation and kits to aid in development. This will significantly reduce the required development time for this approach.

Our requirements call for the capability to sample at least 3 FM broadcasts simultaneously. We will need three FM tuners to fulfill the requirement. The numbers given below are base on the design decisions discussed in section 5.2.2. Estimated Cost: $5.2512 Estimated Design Time: 30 hours Risk: 70 Flexibility: 15

Single Multiplexing Tuner :

This alternative would use a single tuner to multiplex between stations at a rate fast enough to sample multiple stations at audio rate. A block diagram of this alternative is shown below in Figure 3.

Figure 3 - Multiplexing Tuner Alternative Block Diagram

In Figure 3 above, the ‘Switching Tuner’ would jump between each station at a rate fast enough

to capture audio from all station in a seamless fashion. This rate would have to be at least 3*44100 or 132300 jumps per second. This data would be fed into an A/D converter and then passed to the processor. The processor would control the tuner and sort the multiplexed data coming from the A/D converter into the three audio streams required. Variations of this frequency jumping technique are used in spread spectrum technologies. Bluetooth also uses a frequency hopping technique. This, in theory, would provide good flexibility. We have not tested this, as we estimate it would take at least 50 hours of design time to build a simple proof of concept device, and it does not change our final design decision either way.

As far as we know this technique has never been used to sample FM. This will make it difficult to design and configure the hardware to do what we want with it. All the demodulation would have to be done on custom designed hardware or software. Estimated Cost: $13.00 Estimated Design Time: 175 hours Risk: 540 Flexibility: 40

Complete Sampling: This option would use an tuner that would select the entire FM band and pass it to an A/D

converter. The signal would then be sampled by the analog to digital converter (ADC) at a rate upwards

12 volume price of tuner * number of tuners, ( $1.75 * 3 )

15

of 40Msamples/ s to sample the entire FM band. This data would then be fed into a digital signal processor (DSP). The DSP would process the sampled data and extract the desired stations and pass them out to the processor. A block diagram of this alternative is shown in Figure 4 below.

Figure 4 - Complete Sampling Alternative Block Diagram

This option would essentially be the equivalent of a software radio. It would give us a lot of

flexibility (we can implement almost any new type of signal processing on the FM signal and the associated audio by just reprogramming either the DSP or the control software. However the cost of an A/D converter and DSP that can process data at those rates (about 80MBytes per second) is much higher than our other options. We would also have to design all of our own demodulation algorithms for our DSP. Estimated Cost: $40 Estimated Design Time: 120 hours Risk: 400 Flexibility: 60

Decision We compared the three alternatives on a basis of cost, flexibility, scalability and ease of implementation. A decision matrix (Error! Reference source not found.) representing our analysis is show below:

Table 8 Solution Implementation Alternatives

Design Time Flexibility Cost Risk

Total Points

Goal 20 5 20 10 55

Multiple Tuners 20 5 20 10 55

Single Multiplexing Tuner 0 2.5 20 4 26.5

Complete Sampling 10 2.5 5 8 25.5 We chose to go with the multiple tuners option. The complete sampling option is just too expensive, and the multiplexing tuner has to many unknowns (we want to make a working model not chart uncharted territory (However, it could be a promising area for future research)) . The multiple tuners option is very strait forward and inexpensive.

16

5.2.2 Multiple Tuners Alternatives There are a couple alternative implementations of the multiple tuners option. Each tuner needs to sample an FM station and supply the audio information to the microprocessor. We could either design our tuners by hand ourselves or purchase a complete FM tuner chip that can do everything we need in a single component.

Design our own tuners/demodulators by hand This would involve taking the RF signal from an antenna, using a custom design to select a station, demodulate the FM, run the resulting audio through an ADC and pass it to the microprocessor. It has the advantage of being cheaper than a single tuner chip, but could be very time consuming to implement. Estimated Cost: $5.25 Estimated Design Time: 120 hours Risk: 470 Flexibility: 0

Use a single FM tuner chip This option would use a complete FM tuner chip that would be digitally controllable and provide RDS tagging information, and stereo analog audio output. The audio would then be run through an A/D converter into the microprocessor. This has the advantage of being much, much easier to implement than building custom tuners by hand. Estimated Cost: $5.25 Estimated Design Time: 30 hours Risk: 70 Flexibility: 10

Decision We compared the two alternatives based on the design criteria described in section 1.1.2. A decision matrix (Error! Reference source not found.) representing our analysis is show below:

Table 9 Tuner Implementation Alternatives

Cost Ease of

Implementation Scalability Flexibility Total

Points Goal 20 20 5 5 50 Design our own tuners/demodulators by hand (except for ADC) 15 10 4 4 33 Use a single FM tuner chip 15 20 5 5 45

17

We chose to use a single FM tuner chip. It is inexpensive (although it may be slightly more expensive than a custom designed tuner) and extremely simple to implement. It also has the added benefit of supplying RDS tag information.

5.2.3 Compression Once we have the analog audio data from the tuner we need to run it though an A/C converter and pass it to the processor. We came up with two conversion options. Doing a direct A/D conversion or using a MP3 encoder chip to convert the analog data to compressed digital data. The microprocessor does not have the processing power to compress two audio streams at the same time. We can simply store the raw audio data in memory but if we compress it, we can store as much as 12 times as much audio in memory13.

5.2.3.2 Direct AD conversion This alternative uses an A/D converter with no compression. The A/D output is the standard pulse code modulation (PCM). These chips are cheaper and take less time to design the interface to the microprocessor. We need to select A/D converter chips for this alternative. We have found dozens of A/D chips that would possibly work for our purposes. However we have selected three A/D chips that stand out for further analysis. The ADC chips we are deciding between are: Table 10 ADC Alternatives14

Cost Max Sample

Rate Quality Audio

Protocol Channels Philips Semiconductors UCB1400 $ 0.40 48kHz 20bit AC'97 Stereo Texas Instruments PCM1850 $ 0.54 96khz 24bit I2S Stereo Analog Devices AD1871 $ 0.51 96khz 24bit I2S Stereo

Table 11 ADC Design Matrix

Design Time Flexibility Cost Risk Total

Points Goal 20 5 20 10 55 Philips Semiconductors UCB1400 10 5 20 10 45 Texas Instruments PCM1850 20 5 17 10 52 Analog Devices AD1871 20 5 20 10 55

13 Miller, Dorian. PDF to MP3 conversion: an alternative method to. 30 July 2003. Department of Computer Science ,University of No. 8 Dec. 2006. 14 Digikey ADCs. Digikey. 8 Dec. 2006 <http://www.digikey.com/scripts/DkSearch/dksus.dll?Criteria?Ref=367714&Site=US&Cat=32965143>.

18

The Philips ADC ranks lowest because it has a higher design time cost of implementing the AC’97 protocol which is more complicated to implement than I2S. The Texas Instruments part looses value from being too expensive. The A/D converter we would choose for this alternative is the Analog devices AD1871. Estimated Cost: $1.53 Estimated Design Time: 30 hours Risk: 70 Flexibility: 5

A/D conversion through mp3 compression chip This alternative uses a special A/D converter that converts the analog data to compressed mp3 data. This allows for as much as 12 times the audio storage capacity. However, it will require slightly more design work for the interface to the processor15. Estimated Cost: $9 Estimated Design Time: 40 hours Risk: 117 Flexibility: 10

Decision A decision matrix comparing these alternates are shown below.

Table 12 - MP3 - A/D Desision Matrix

Design Time Flexibility Cost Risk

Total Points

Goal 20 10 20 10 55 Direct AD conversion 20 5 20 10 55 ADC conversion through mp3 compression chip 15 10 8 7 40

The mp3 compression chip loses in the decision matrix, however we decided to use the mp3 compression chip as the benefit of the added recording time outweighs the increase in cost. The other design criteria are fairly consistent across both alternatives. The cost of memory in our production model is $4. The mp3 compression chip will allow us to store as much as 12 times (we will use 10x in our calculations to be conservative) the audio in the same amount of memory16. To provide the same increase in storage capacity by simply increasing the amount of memory by 10 times would cost $40. The compression chip costs $3, but we will need three of them for a total of $9. It is about $31 dollars cheaper to use the mp3 chips to increase our storage capacity.

15 Miller, Dorian. PDF to MP3 conversion: an alternative method to. 30 July 2003. Department of Computer Science ,University of No. 8 Dec. 2006. 16 Miller, Dorian. PDF to MP3 conversion: an alternative method to. 30 July 2003. Department of Computer Science ,University of No. 8 Dec. 2006.

19

6 Testing Testing will take place on a requirements basis. The requirements will be classified by the type of requirement and tested accordingly. If a requirement is not able to be physically tested it will be met by inspection. If a requirement needs more to verify then it will be tested to make sure that it meets the requirements.

6.1 Physical Physical requirements will be verified by inspection. This includes measurements of certain components and physical aspects that can verified without any technical measurements.

6.2 Functional The functional requirements will be verified by tests using equipment from the engineering lab. The equipment we will need to test is an oscilloscope, digital multi meter, and Altera dev kit.

6.3 Testing Table Table 13 listed below shows the requirements that we will test and the method in which we intend on testing them.

Table 13 Testing Procedure

Requirement: Verification Method Result (Pass/Fail) Name of Tester

Functional:

The device must be able to sample FM radio audio data from no less than 2 FM broadcasts simultaneously in stereo quality Inspection

The device must allow the user to select any station in the FM band for listening Testing

The device must allow the user to pause (for no less than 5 minutes) and resume, one radio audio stream. Testing

The device must allow the user to listen to one radio stream, switch to a second radio stream and rewind up to 5 minutes, the second stream. Testing

The user must be able to rewind or fast-forward the active stream at a rate of 10 seconds of recorded time per 1 second of real time. Testing

fmNOW will be able to store data onto an onboard memory source Testing

Performance: Power

fmNOW will be powered by an DC power source Inspection

Size:

The device must be no bigger than a form factor of 1’ x 6” x 8” (W x H x D) Inspection

Weight: The device must weigh no more than 10 lbs Inspection

20

Quality:

The device will minimally be able to store radio streams at a rate of 44.1kHz at 16 bit digital quality providing a net raw digital quality of 172KB /s [1] Testing

The device must be able to playback audio streams at 44kHz Testing

Cost: The prototype can cost no more than $360 Inspection Storage:

The device shall be able to record up to 5 minutes per station Testing

Interface :

The user interface must be reasonably intuitive with controls similar to those of current radios and music listening devices. Inspection

The interface must allow the user to select an FM broadcast to listen to Testing

The interface shall show the current station that is being listened to as well as the other stations being recorded Testing

The interface shall be able to show different screens to show different functions Testing

If a button shall be considered pushed once it has been engaged, not when it is released. During the period when the button is held down, pushing another button will not do anything. Testing

A button push shall cause a noise to indicate to the user that it has been pushed Testing

The interface must allow the user to pause, resume, or rewind an active broadcast. Testing

The interface must allow the user to pause, resume, rewind, or forward a recorded broadcast. Testing

The interface must allow the user to switch from a paused broadcast to any another broadcast and vice-versa Testing

The interface must allow the user to turn fmNOW on and off Testing

fmNOW will have a light that signals to the user if the unit is on or not Inspection

7 Project Management

7.1 Schedule We have put together an overall project schedule and timeline which can be found in Appendix C. Now that the first semester is complete, we have our prototype design finalized and we have a good idea of how the production design will differ. We are now beginning construction of our prototype. One of our

21

goals is to have all of the chips and internal parts of the prototype ordered before December 15th. During interim, we plan on laying out block diagrams for the software. Once our parts arrive and the second semester begins, we will start putting the various pieces together and work on system-level communication. Our debugging process will be ongoing throughout the semester. We plan on splitting up the device into components, bringing each component up individually, and debugging each component before combining them into larger blocks. More specifically, we will begin by wiring up the tuner chip to an Altera DE2 board. We will use the DE2 board as a controller for the tuner and connect speakers to see if we can receive different stations. This should be easier than using the SBC initially because we are already familiar with the functionality of the DE2 boards. Once we accomplish this, we will attempt to use our SBC as our controller and debug the system until we get each subsystem working. We estimate these tasks to take us approximately four weeks. This puts us at the beginning of March. We also hope to have this same process going on at the same time for the mp3 encoder/decoder interface with the SBC. We estimate that the mp3 to SBC interface will take approximately a week longer than the tuner interface because it will be more difficult to test and debug. We also plan to start writing the software at the beginning at the beginning of the second semester. We estimate that the initial version of the user interface will take no more than three weeks to complete. Once we get the different hardware components of the device together, we can finalize the way the user interface interacts with hardware.

7.2 Work Breakdown Structure

Senior Design Project Expected

Hours Actual Hours

Final Report 200 0Compile First Revision 150 0Peer Revision of Final Report 50 0

Write Project Proposal and Feasibility Study 82 133Write the Abstract 1 1Write background setting (research, etc.) 8 12Cost Analysis 8 15Design Alternatives 8 10Objectives 1 5Requirements 2 5Task Specifications 2 6Schedule 1 3Monthly Budget Report (last day of month) 1 2Peer Revision of PPFS 50 74

Presentations 24 13Presentation 1 6 7Prepare/Write 5 5Practice 1 2Presentation 2 6 6Prepare/Write 5 5Practice 1 1Presentation 3 6 0Prepare/Write 5 0Practice 1 0Presentation 4 6 0Prepare/Write 5 0

22

Practice 1 0

Design fmNOW 1410 114Research 130 62RDS 20 12Tuning Methods 20 15DSP 20 10Recording Medium 20 5Processors 30 10LCD 20 10Prototype Hardware Design 575 26Decision Making 14 26Group discussion and brainstorming 8 20Construct Design Matricies 4 5Meet with team mentor 2 1Prototype construction 561 0Order Parts 1 0Establish Tuner to SBC interface 100 0Establish mp3 to SBC interface 100 0Write initial software 100 0Revise and debug software 50 0Assemble all hardware components of device 50 0General debugging of overall device 100 0Tweek user iterface 60 0Prototype Software Design 375 0Write software requirements 10 0Write software 250 0Block Diagram 20 0Debug 70 0choose design alternatives 25 0Production Hardware Design 35 26Group discussion and brainstorming 20 20Construct Design Matricies 10 5Meet with team mentor 5 1Production Software Design 295 0Write software requirements 20 0Write software 200 0Block Diagram 10 0Debug 50 0choose design alternatives 15 0

Webpage 10 6Original construction 5 6Updates 5 0

Poster 6 6Original construction 5 4Updates 1 2

Advertisement 3 5Design 2 4Updates 1 1

23

Project Brief for Industrial Consultant 3 3Compile document and prepare 2 2Meeting time 1 1

Project Brief for Industrial Consultant 2 12 0Compile document and prepare 10 0Meeting time 2 0

Total Hours 1750 280

7.3 Team Organization Our team consists of five members. Each member has a different responsibility to the group. Jordan Schaenzle is in charge of project scheduling. His job is to keep track of the due dates for the group. This helps to make sure that we do not miss any of the deadlines. Peter Tuuk is in charge of the project proposal and feasibility study (PPFS) and keeping it up do date. When things change he is responsible for updating the report. He is also responsible for giving the tasks to other group members and putting the sections of the PPFS together. Job Vranish is responsible for the status reports. All of the group members need to submit the tasks they worked on and the amount of hours they worked for the week so he can organize them and send them to Professor VanderLeest by the specified time. Along with this, Job is in charge of monitoring the progress of the action items to make sure they are getting completed. Brad Zoodsma is the group lead. He is responsible for maintaining a constant flow of the entire project; that is keeping track of the research, different components of the design, and deadlines of the project. Mike Zwagerman is in charge of the budget. He will keep track of all the money that has been spent on the different components, and how much we have left. He will also do research on the cost of the different options for parts. In the second semester Mike will focus on the business plan.

7.4 Methods of Communication Our group uses many methods of communication. The most-used method is email. We use email to send documents, and memos to each other. We also use Google Docs and Spreadsheets to have a common place to save documents when we work off campus. Job Vranish also created a time card webpage to aid in combining our weekly status reports.

7.5 Conflict Resolution Our group has come up with a couple methods of conflict resolution for different situations. If our group does not agree on different design decisions, we take a vote. Our group is lucky in that we have an odd number of members so when we take a vote we always have a majority. Our members have been getting their work done on time, but if one member is not getting his work done on time we confront him. If he has a good reason we let it go and help him out with his tasks and get him caught up again. If he does not have a good reason we reprimand him and make him change his ways.

8 Research

8.1 Patents Our device relies on technologies used in other existing devices. To our satisfaction we have found that the concept of fmNOW is novel. Using the United States Patent and Trademark office’s online search tool we found that no product has been patented that is equivalent to fmNOW. Several companies have received patents for radio devices which incorporate Radio Data System (RDS) and Radio Broadcast Data

24

System (RBDS) information tagging, and digital FM tuning, however we were unable to find any patents for an FM radio that is capable of pause and rewind functions like our design. As mentioned earlier, there are products on the market that have similarities to our device. The technology of recording songs and audio clips for later listening has been implemented and patented by ADS Tech. Their product, Instant FM Music™ (US Patent #5790958) is a complete USB hardware/software package that interfaces with a personal computer. The device records the user’s favorite songs, podcasts, and sporting events automatically, and separates and identifies the songs for easy playback. Instant FM Music™ is similar to fmNOW but has key differences. ADS Tech’s product is not designed to operate independently from a computer, while fmNOW has the capability of being without a computer17. Another product with similar features to fmNOW is Griffin Technology’s iFM™. This device plugs directly into an iPod™ providing additional FM radio features. The iFM allows the user to listen to FM radio broadcasts via the iPod™. If the “Record” button is pressed, the iPod™ will record the FM broadcast and store it in the iPods™ internal memory. The amount of audio time which can be stored is only limited by the iPods internal memory space. This device is also similar to fmNOW, but with several key differences. First, iFM™ does not allow the user to rewind the radio while listening to it. The user must first record the audio file, then go to the media library and play the clip as if it were any other audio file on in the iPod’s™ memory. Another difference is that iFM™ does not continually record a station. If a user tunes to a station and finds that a song is half over there is no way to listen to the beginning of the song. Griffin Technology does not have a patent for this device. We assume this is because all their product really does is record FM music and they did not invent the technology used to do that18. There are many other products in the market that can record digital media, such as DVR’s and mp3 recorders. However, we have not come across a device that allows a user to rewind an FM broadcast as its playing and listen to it again. We have come across a couple other websites where people have mentioned that they working on such a device or have mentioned the need for such a technology, but too our knowledge, none have done it. For this reason, we believe that our device is innovative and could possibly be patented.

8.2 Market Study fmNOW design objectives place us in competition with other radio manufacturers. Our solution provides us an added value solution to existing radios with coincides with future customer preferences and trends. Ofcom (Office of Communication), the official regulator for the UK communications industries, conducted three workshops in June 2004. They performed 24 in-depth interviews and carried out a survey of 1,000 people across Britain. They found that 26% of people are very interested and 32% of people are quite interested in a device that provides pause, rewind and live broadcasts recording capabilities.19 We also found that there are 70 million radios sold in the United States every year.20 fmNOW therefore

17 McCoy, M.S. U.S. Patent 5790958, 1995, United States Patent and Trademark Office. 18 Deitz, Corey. "iFM Turns iPod into FM Radio, Recorder and Remote Control." About.com: Radio. 31 July 2005. 7 Dec. 2006 <http://radio.about.com/od/pdasipodscellphones/a/aa073105a.htm>. 19 Devices and Desires of the Next Generation of Radio Listeners. 23 July 2004. Ofcom. 8 Dec. 2006. 20 Digital radio hailed by broadcasters but faces challenges. 2005. The Associated Press. 6 Dec. 2006 <http://www.usatoday.com/tech/news/techinnovations/2002-10-21-digital-radio_x.htm>.

25

decided that a reasonable estimate for the first year production units is approximately 33% of the interested 58% of 70 million totaling 13,398,000 units. Most of our market research has been done for the purpose of planning the physical properties of our device. Amazon.com was used to perform a market survey of countertop and tabletop radios. The products that were found and used for this study can be found below. Based on this study and our prior knowledge of electronics, we have determined that the device should meet the following criterion: The device should weigh no more than twenty pounds so that it can be moved easily. The device will most likely have a rectangular shape of the smallest size possible so that it does not take up much space on a counter or table. The market study showed that maximum dimensions for these types of radios are 18.5 x 14.5 x 14 inches (W x H x D). Our target size has been set at 1’ x 6” x 8” which puts us well within the acceptable size. Our study also showed that the price of home radios ranges from inexpensive models around $20 dollars to the higher end radios which sell for around $500. Our goal is to make our product as inexpensive as possible so that it can be available to more people. Our estimated cost of production is about $36.22. We would like to have a profit margin of 50%. We also assume that there will be an estimated mark up of 100% from production to distributor and a further estimated 100% markup from distributor to retailer. Our estimated retail price then is $217.32

9 Feasibility This section will address the possibility and probability of success on this project. This includes the analysis and management of risk as well as the concluding remarks about the feasibility of the project as currently defined.

9.1 Risks

9.1.1 FM Radio Reception

9.1.2 Analysis: Working with the radio frequency is a challenge because of the tendency of high-frequency signals to interfere with neighboring lines. Acquiring and demodulating wireless transmissions is a sensitive task, especially when working with analog resistor, inductor, and capacitor tuning circuitry.

9.1.3 Mitigation: We hope to use packaged integrated circuit radio tuning device which will operate reliably and with minimal external tuning circuitry. Digital tuners are more stable and reliable than their analog counterparts and will give us greater control over tuning using the microprocessor.

9.1.4 Intra-System Interfaces

9.1.5 Analysis: The fmNow system will be comprised of many different parts. Not all these parts use interfaces that are meant to work together. To communicate information and control over these channels will require careful management of I/O on the microprocessor and detailed analysis of timing diagrams and operation of the various elements that interact with the microprocessor.

9.1.6 Mitigation: We have selected a microprocessor with GPIO sufficient to communicate with multiple elements. We have also elected to use parts that operate using interfaces like Inter-Integrated Circuit (I2C), Inter-

26

Integrated Circuit Sound (I2S), or Serial Peripheral Interface (SPI) that are compatible with our selected microprocessor.

9.1.7 Schedule and Deadline Keeping

9.1.8 Analysis: Another area of risk will be schedule and deadline keeping. With a complicated project, falling behind schedule is possible. Unless we order parts early enough and stay involved through the January interim, we could be caught unaware and behind.

9.1.9 Mitigation: To keep ourselves on schedule and to keep one aspect of the design from pushing the entire product behind schedule, we have established a set of project milestones. These are achievements that must be met in order to proceed. This information can be found in Appendix B. This will give us reminders and checkpoints to keep our project on-time.

9.1.10 Content Tagging

9.1.11 Analysis: Though tagging audio files is not a requirement for success on the project, it is a desirable feature. If we attempt to implement this content-tagging, some challenges will have to be surmounted. The content sent via RBDS or RDS is not standardized and would therefore be difficult to parse. Also, to receive and decode the radio data tags is unproved using our current technology. Lastly, coordinating the received content tags and delineating tracks will require additional file system features.

9.1.12 Mitigation: To mitigate these risks we have selected parts that will allow us to expand our scope to include the feature of content-tagging if that is decided to be a goal worth pursuing.

9.2 Conclusions This project is feasible from a few standpoints.

9.2.1 Financial Using resources already in the College’s possession has enabled Team 1 to make the most of its limited budget. Given the resources we have already acquired, the production of a one-off prototype is within the means of Team 1.

9.2.2 Scope With the requirements defined as they are, the project is feasible. There are a number of features the team would like to build into fmNow which are not requirements. If too much time is devoted to these tasks, the requirements may not receive enough work, and the project as a whole may fall. If scope creep is avoided, the scope is manageable, as evidenced in our project management schedule.

9.2.3 Design This design does not break new technical ground. It is an original integration of other existing technologies. For this reason, Team 1 does not need to develop novel methods, techniques, or hardware. This gives us confidence in the feasibility of the project.

27

Furthermore, we are a multi-talented group. Team 1 is comprised of members skilled in software design, hardware design, project management, and testing and verification. This diverse talent base will give Team 1 a solid foundation on which to build the fmNow project and to succeed within the context of the Engineering 339/340 course.

10 Sources Amazon.com. 5 Oct. 2006 <http://www.amazon.com/audio-video-portable-accessories/b/ref=gw_br_av/104-9719720-0943950?%5Fencoding=UTF8&node=1065836>. Current Trends in Flash Memory Technology. Ed. Sang Min. School of Computer Science and Engineering. 8 Dec. 2006. Deitz, Corey. "iFM Turns iPod into FM Radio, Recorder and Remote Control." About.com: Radio. 31 July 2005. 7 Dec. 2006 <http://radio.about.com/od/pdasipodscellphones/a/aa073105a.htm>. Devices and Desires of the Next Generation of Radio Listeners. 23 July 2004. Ofcom. 8 Dec. 2006. Devices and Desires of the Next Generation of Radio Listeners. 23 July 2004. Ofcom. 8 Dec. 2006. Digikey.com. 26 Nov. 2006 <http://www.digikey.com/>. Digikey was used as reference for pricing and technical data sheets. The following Digikey part numbers were referenced: 336-1379-ND, 568-1323-1-ND, 598-1046-5-ND, 497-3939-1-ND, 296-16929-ND, 497-3939-1-ND, AD1871YRS-ND, 568-1158-5-ND "Digital Audio Broadcasting" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/Digital_audio_broadcasting>. Digital radio hailed by broadcasters but faces challenges. 2005. The Associated Press. 6 Dec. 2006 <http://www.usatoday.com/tech/news/techinnovations/2002-10-21-digital-radio_x.htm>. "Flash Memory" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/Flash_Memory>. "Frequency Modulation" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/FM>. GNU Radio - The GNU Software Radio. 15 Nov. 2006. 24 Nov. 2006 <http://www.gnu.org/software/gnuradio/>. "GNU Radio." Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/GNU_Radio>. Intel XScale® Core Developer's Manual. Jan. 2004. Intel. 8 Dec. 2006. McCoy, M.S. U.S. Patent 5790958, 1995, United States Patent and Trademark Office. Miller, Dorian. PDF to MP3 conversion: an alternative method to. 30 July 2003. Department of Computer Science ,University of No. 8 Dec. 2006.

28

PERT. Internet Center for Management and Business Admi. 8 Dec. 2006 <http://www.netmba.com/operations/project/pert/>. "Radio Data System." Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/RBDS>. Sony Corp. v. Universal City Studios, Inc., 464 U.S. 417 (1984). "Streaming Media" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <"Digital Audio Broadcasting" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/Streaming_media>. "Superheterodyne Receiver" Wikipedia: The Free Encyclopedia. 8 Dec. 2006 <http://en.wikipedia.org/wiki/Super_Heterodyne_receiver>.

29

Appendix A Market Research

Bose Wave Music System - Platinum White Price: $499.00 Product Dimensions: 8.6 x 14.6 x 4.2 inches ; 8.7 pounds Classic CRL11 Sunset Melodies AM/FM CD Nostalgic Cathedral Song Console Measures 11.8 x 14.8 x 11 inches (W x D x H) Shipping Weight: 13.00 pounds

Panasonic SC-PM03 Executive Microsystem list price: $99.00 Dimensions: 18.5 x 11.7 x 8.8 inches ; Shipping Weight: 23.00 pounds

Boston Acoustics Recepter Radio AM/FM clock radio with dual alarms White $149.99 Shipping weight: 4.9 Pounds No size listed

Tivoli Platinum Series Model One Henry Kloss table radio Piano black $199.99 Shipping weight 5.56 pounds Actual weight: 4.52 pounds Dimensions: 4.5"H x 8.375"W x 5.25"D 11.43cm H x 21.27cm W x 13.34cm

JWin JL-K733 Under-Counter AM/FM Clock Radio with CD Player $34.95 Product Dimensions: 15.0 x 5.0 x 10.5 inches

Shipping Weight: 6.00 pounds Teac SR-L35W Wall-Mounting or Tabletop Stereo with CD Player and AM/FM Tuner, White $123.75 Measures 15 by 9 by 4.6 inches (W x H x D); includes remote control Weight 9.5 pounds

Crosley CR37 Bluebird AM/FM Radio with Cassette Deck

30

Price: $129.95 Measures 14 x 14 x 7.5 inches (W x H x D) Shipping Weight: 11.00 pounds

JWIN JLK533 Kitchen Under-Counter AM/FM Clock Radio With CD Player Price: $34.50 Measures: Not Available Shipping Weight: 7.00 pounds GE 75300 GE Slim Spacemaker CD player with Digital Clock and AM / FM Radio, Under-Counter Mounting system. Price: $89.99 Product Dimensions: 5 x 15.6 x 13.7 inches Weight: 8.3 pounds Crosley Radio CR221 Solo Radio Price: $114.99 Weight: 6.00 pounds Dimensions not available

31

Appendix B Project Milestones Milestone 1

Preliminary design / Parts list -- order parts Get the SBC to boot Linux and communicate on the development board Finish PPFS

Milestone 2 (February 12th)

Get an FM chip to work on a breadboard (we should be able to hook it up to headphones and listen to FM) Get the ADC's and digital audio converters (DAC) (probably audio codecs) to interface to the SBC (should be able to record audio to the SBC and then later, play it back over the DAC's and listen to it on headphones again) Get the audio compression/decompression working on the SBC or get it to work on an encoding chip

Milestone 3 (February 26th)

Get the SBC to interface to the LCD and display a GUI Get the SBC to interface to the touch screen (optional) Get the SBC to control the FM chip and read RDS information Contingency plans if failed to accomplish goals in Milestone 2:

Pray If we can’t get the FM chip to work, possibly use alternate chip, otherwise use simple radio shack radio and hook it up to the ADC If we can’t get the ADCs to interface properly, use the UCB 1400 (as it was designed for this SBC) for now but continue to work on getting the other ADCs to work (possible switch to another ADC)

Milestone 4 (March 12th) Get software fully functional Get the full path from antenna to SBC and out to speakers to function properly on breadboard.

Design a complete circuit layout Order PCB Contingency plans if failed to accomplish goals in Milestone 3:

If we can’t get the LCD to work, use simple switches for our user interface for now, but keep working on it. If we can’t get the touch screen to work, skip it. If we have trouble reading the RDS tags off of the FM chip, skip it. If we have trouble controlling the FM chip in general, we might consider switching to alternative chip, but if we got it to work on the breadboard in milestone 2, we should be able to get it to work here.

Milestone 5 (March 26th)

Get the full system running on PCB Prepare demos for the exhibit

32

Contingency plans if failed to accomplish goals in Milestone 4:

Milestone 4 is mostly an integration milestone so there is not much we can do as far as alternatives except keep trying. We may possibly drop non essential features if we simply cannot integrate them, but this would only be a last resort.

Milestone 6 (April 9th) Write final report

Contingency plans if failed to accomplish goals in Milestone 5: If we can’t get the full system to run on the PCB we will demo the breadboard version.

Milestone 7 (April 23rd) Finish anything that was pushed off.

33

Appendix C

34