EE 477 Final Report - Purdue University



ECE 477 Final Report

Fall 2004

[pic]

Team Code Name: ____________The Wrecking Cru_________________ Team ID: Cru_

Team Members (#1 is Team Leader):

#1: _______Sumit Mehra__________ Signature: ____________________ Date: _12/14/04_

#2: _______Pranav Kabra_________ Signature: ____________________ Date: _12/14/04_

#3:_______Brandon Fane_________ Signature: ____________________ Date: _12/14/04_

#4: ______Mohnish Rathi_________ Signature: ____________________ Date: _12/14/04_

REPORT EVALUATION

|Component/Criterion |Score |Multiplier |Points |

|Abstract |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|Project Overview and Block Diagram |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Team Success Criteria/Fulfillment |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Constraint Analysis/Component Selection |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Patent Liability Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Reliability and Safety Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Ethical/Environmental Impact Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Packaging Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Schematic Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|PCB Layout Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Software Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Version 2 Changes |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|Summary and Conclusions |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|References |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix A: Individual Contributions |0 1 2 3 4 5 6 7 8 9 10 |X 4 | |

|Appendix B: Packaging |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix C: Schematic |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix D: Top & Bottom Copper |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix E: Parts List Spreadsheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix F: Software Listing |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix G: User Manual |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix H: FMECA Worksheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Technical Writing Style |0 1 2 3 4 5 6 7 8 9 10 |X 5 | |

|CD-R of Website Image |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

| |TOTAL | |

TABLE OF CONTENTS

|Abstract |1 |

| 1.0 Project Overview and Block Diagram |2 |

| 2.0 Team Success Criteria and Fulfillment |2 |

| 3.0 Constraint Analysis and Component Selection |2 |

| 4.0 Patent Liability Analysis |8 |

| 5.0 Reliability and Safety Analysis |12 |

| 6.0 Ethical and Environmental Impact Analysis |17 |

| 7.0 Packaging Design Considerations |21 |

| 8.0 Schematic Design Considerations |25 |

| 9.0 PCB Layout Design Considerations |28 |

|10.0 Software Design Considerations |29 |

|11.0 Version 2 Changes |33 |

|12.0 Summary and Conclusions |33 |

|13.0 References |34 |

|Appendix A: Individual Contributions |A-1 |

|Appendix B: Packaging |B-1 |

|Appendix C: Schematic |C-1 |

|Appendix D: PCB Layout Top and Bottom Copper |D-1 |

|Appendix E: Parts List Spreadsheet |E-1 |

|Appendix F: Software Listing |F-1 |

|Appendix G: User Manual |G-1 |

|Appendix H: FMECA Worksheet |H-1 |

Abstract

We aim to build a stand alone wireless digital audio receiver. The CRU (Cru Radiation Universe) will receive mp3 songs from up to 3 computers via 802.11b wireless protocol and relay the audio through a regular stereo output. The mp3 files will be stored on a mini USB drive. The CRU will also contain an LCD display which will display the song details based on the ID3 tag of the song.

The software on the computers will ascertain the order of the songs, and once played they will be released from the drive. The motivation of this project is to provide apartments with multiple computers, and hence, multiple audio collections to have a single place to output their music, quite often in another part of the residence. This can also be used as a portable device to be taken to a friend’s residence for use there. A 5 volt D.C. “wall-wart” will be used as a power supply.

1. Project Overview and Block Diagram

[pic]

2. Team Success Criteria and Fulfillment

1. Ability to decode/play an MP3 file.

2. Ability to control mode of operation via keypad.

3. Ability to display song information on an LCD display.

4. Ability to save/load MP3 file to/from xD picture card.

5. Ability to transfer MP3 files via wireless 802.11b link (from a remote host).

Constraint Analysis and Component Selection

Computational Requirements

For computational requirements, there were four main operations that we needed to consider. Choosing a processor which operated at a speed sufficient enough for our requirements was a critical component decision. The first major computational requirement was to determine the transfer rate from the networked computers to the Rabbit. This needed to be fast enough to download an MP3 and also not eat up too much processing power or time in general. Since TCP/IP is available on the Rabbit, this could be done at a full 10Mbps [1], decidedly fast enough for our operation.

The next major concern is communicating and supplying a viable bit stream to the MP3 decoder. The Decoder chip uses two separate interfaces for its data and control bit streams [2]. Our processor will need to be able to keep up with the data needs of this chip so that our goal of continuous music can be achieved. Choosing a processor capable enough of performing the above computational requirements as well as achieve a seamless music stream is absolutely necessary to project success.

Interface

Interfacing is another key concern we had when deciding which processor to choose. Most of our interfacing computation will be done using external hardware, reducing computational load on our micro controller. Interfacing concerns, however become integral to a “good fit” micro controller for our design.

Our first interface is to a 2x24 LCD. The LCD will allow the user to view the status of the device during operation. The LCD we have chosen requires an 8-bit parallel interface and 3 bits for its data and control registers respectively. This requires a total of 11 parallel port pins on our processor available for this device [3].

The next and probably most important interface is the MP3 decoder chip. This will eventually decode our MP3 files and send them out to the stereo as regular audio output. With one SPI interface, and one I2C interface, this chip requires 2 serial port pins, and 2 generic I/O pins to serve as data and control clock pins respectively, 2 byte synchronization bits, and two more generic I/O pins for the data request pin and the chip select pin are also needed. To summarize, this interface will need 2 serial port pins, and 6 parallel and/or generic I/O pins for the rest of its control signals [2].

Last but not least is the Keypad Encoder IC interface. This chip allows the keypad on the Cru to be decoded with no software concerns in our micro controller. With simply a 4-bit parallel data bus and one Data Valid Output pin for interrupts, this encoder chip only requires 5 parallel port pins for operation and communication with our micro controller [4].

In total our Interfacing constraints are as follows: 35 parallel port pins and 2 serial port pins. This means we will need to take this into heavy considerations for the final selection of our micro controller. Given limited I/O capabilities on the Rabbit 3000, a bit of caution needs to be taken for our interfaces

Power Supply Constraints

|Part Description |Voltage Req. (V) |Current Req. (mA) |

|Rabbit 3360 Core Module |3.3 |350 |

|LCD Screen |5 |5 |

|MP3 Decoder IC |3.3 |55 |

|Keypad Encoder IC |5 |1.8 |

| | | |

|Total Power Req. | |411.8 |

Table 1 Power requirements for individual components

Looking at Table 1 it has been determined that an initial supply voltage of 12Vdc will be needed to satisfy the voltages requirements from all of our devices. Linear regulators will be used to achieve the other prescribed voltages. Summing the current draws of all of our components gives a total current sourcing need of 438.1mA. To account for other unforeseen power needs (indicators, LEDs, etc.), a 1A 12VDC “wall wart” power supply will be used. This will ensure that all current sourcing needs are met with a reasonable factor of safety and that all appropriate voltages can be created through the use of regulators.

Packaging Constraints

Our packaging estimate is based on the assumption that the PCB will measure approximately 5.5” X 7”. In addition to the PCB space, we are making accommodations for a ventilation fan, if needed, the LCD display, a keypad and its encoder IC, and possibly internal wireless bridge, wiring, LEDs and miscellaneous connectors. The estimated device size is 7” X 9” and an estimated height of 3”. Since we are using an external power supply, its weight will not be accounted for in our package. A worst-case estimation sets the weight at no more than 2 lbs. Most components have nominal weight (PCBs, LEDs and wire connectors); hence our device will be very light. The fan(s) might take up some weight, but it’s nothing very substantial.

Cost Constraints

|Component |Cost |

|RCM 3300 |$69.00 |

|MP3 Decoder Chip |$19.52 |

|USB Host Controller |$5.64 |

|LCD Screen[1] |$9.50 |

|Keypad |$11.50 |

|Keypad Encoder IC |$7.50 |

|Packaging Costs |$20.00 |

|Wireless Router Module |$15.00 |

|Total Cost |$157.66 |

Table 2 Cost of components

From Table 2 above, we can see a total production cost of $157.66. Adding in labor time and various other components (resistors, caps, LED s, etc), the estimated total cost in the market of the Cru would be around $200.00 per unit.

Rationale

Central micro controller -- Rabbit RCM 3360

Competition:

• Motorola 68HC12 [5]

• ATMEL AVR ATmega64 [6]

Our first concern when selecting a central micro controller was for it to have complete TCP/IP functionality. Another concern was ease of programming the micro controller. The Rabbit 3000 has TCP/IP libraries readily available for use implemented using Dynamic C 8.69, a hybrid version written specifically for Rabbit controllers. Although there is also a good C compiler for using the HC12 and we are more familiar with its operation, there were some I/O differenced that worked against the HC12 when it came to selecting our micro controller. The HC12 has 3 generic parallel ports, as compared to 7 on the RCM3360, which would boost our I/O capabilities immensely. Also, only 1 serial port is available on the HC12 while there are 6 on the RCM3360, which gives us more room and flexibility for our programming. Also the RCM3360 comes with 512k of flash memory, where as the HC12 only has 256k of flash memory. Our programming concerns made us worry whether or not the HC12 could accommodate the amount of programming necessary to complete our project. Finally, the HC12 does not come with any TCP/IP capabilities already available. This would require us to use external hardware and additional software in order to get our device on a network. This would create an even greater need for I/O on the micro controller as well as more memory requirements. Since the HC12 already lags behind the RCM3360 in both these respects, this is the deciding factor in ruling out the HC12 for our purposes.

Another competitor was the ATMEL AVR ATmega64. Although this was the only ATMEL processor that would meet our I/O needs, the Mega64 also had some shortcomings. The first is that it does not have readily available TCP/IP libraries or the RJ-45 jack built in to any of its modules like the RCM3360. Although the mega64 has 7 parallel ports like the RCM3360, it only has two serial lines. Since we require two serial ports for our MP3 decoder IC, the flexibility of the RCM3360 with 6 serial ports was quite attractive. I/O aside, there is also the issue of ease of programming. Although ATMEL also has a C to assembly converter for its micro-controllers, the lack of readily available TCP/IP libraries would have made network interfacing very difficult. The TCP/IP issue eventually convinced us to choose the RCM3360 over the AVR mega64.

Rationale for MP3 Decoder IC:

Chosen MP3 Decoder IC:

• STA013 MP3 Decoder Chip[2]

Competitor:

• VLSI VS1001k[7]

Two MP3 Decoder ICs were considered for use in the Cru; the STA013 and the STA013. While both candidate decoders had similar operating voltages and frequencies, there were some major differences that influenced our choice.

While the STA013 had much more online documentation and many application notes, the STA013 was the only chip which combined the MP3 CODEC, Digital to Analog Converter and the earphone driver amplifier all in one package. For the sake of ease of programming and availability of parts, we decided to go with the STA013 MP3 decoder. Although this will entail a slightly more complicated board layout and schematic design, its I2C interface for sending commands makes communication with the device much more standardized and easy to understand.

3. Patent Liability Analysis

.

Results of Patent Search

#6,728,585[1] Personal On-Demand Audio Entertainment System

The patent is described as a “personal on demand audio entertainment system”. The patent number is 6,728,585. The system consists of a base unit and a headphone unit which is worn by the user. The base unit is attached to a personal computer and transmits digital audio information to the headphone unit via infrared, radio frequency, or some other form of wireless communication. The headphone unit takes the received digital audio and stores it in solid state memory until it is played. Once retrieved from memory, the digital audio information is converted into analog audio signals and sent to the headphones for the user to listen to the song. The user can prompt for songs as he or she wishes, thus making the device “on demand”. The remote control unit has control over audio characteristics such as volume, bass, treble and balance.

The patent makes 33 claims out of which the Cru uses claim 3, 14, 15, 25 and partially claims 1 and 2. The patent states that the device uses radio frequency to transmit songs to the headphones and has a remote control to control the audio characteristics using infra-red. The device does not specify the solid state memory storage used for storing downloaded songs and uses an amplifier and a transducer to modify the audio signals before playback.

#6,684,060[2] Digital wireless premises audio system

This patent is described as a “digital wireless premises audio system” and “a home theater system incorporating the audio system”. The abstract of the patent describes the device as

“A digital wireless premises audio system. In one embodiment, the audio system include: (1) a digital audio encoder/transmitter that accepts and audio channel in digital form, encodes the channel into a stream of digital data and wirelessly transmits the stream and (2) a speaker module that receives, decodes and converts the audio channel into analog form”

The Cru in essence performs the same tasks as described by the patent although it does not execute those in the same way. The first claim of the patent was to use a “digital audio encoder/transmitter that accepts a plurality of audio channels into a stream of digital data and wirelessly transmits said stream using Bluetooth” There are three claims, 4,7 and 12 in the patent which the Cru partially uses out of a total of 19 claims made by the patent. Some of the claims which are used in the implementation of the Cru are “a method of wirelessly transmitting data and converting digital audio channels to analog form” and a digital converter that decodes the audio channel. The device, however, also encodes an audio channel before transmitting wirelessly to the speakers, amplifies the decoded analog audio channel conforming to several audio standards such as Dolby-RTM-Stereo, four-channel quadraphonic, and Dolby-Surround 5.1 which is non-existent in the Cru.

#6,684,060[3] System for playback of network audio material on demand

This patent is described as a system for playback of network audio material on demand. The abstract of the patent describes the device as a,

“Playback unit resembling a home audio component retrieves audio data from a remote server and plays them back in real time, using home audio system, in response to user selection. The playback unit can retrieve audio material from the network on demand, thereby vastly expanding the range of music available for playback, and reproduce the music using home audio system for high quality playback, with controlled access to audio material and controlled distribution and duplication of material”.

Once again the Cru performs the same tasks as claimed by the patent especially claims 8, 10, 14, and 20 and partially claims 1 and 19. The main difference between this patent and the implementation of the Cru lies in the fact that the songs are retrieved from a network and stored in the device once a request is sent by the user. However, the Cru has not access to any server for songs and all the songs played are sent by the user directly.

Analysis of Patent Liability

The Cru does not literally infringe on any of the above listed patents. The Cru has some similarities in the tasks described in all the three patents however it does not work as the devices mentioned in the patents in totality. There are, however, a few infringements under the principle of ‘Doctrine of Equivalents’ as described below.

# 6,728,585 Personal On-Demand Audio Entertainment System

This would be an infringement under the doctrine of equivalents. The device described by the patent uses radio frequency to transmit songs to the headphones. However, the Cru is designed to strictly allow transfer of songs using IEEE 802.11b protocol. The device has an in-device solid state storage for saving songs to be played back on the headphones. The Cru, on the other hand, uses a removable xD card memory for storage which comes with the RCM 3360 module used in Cru. Since the patent is not categorical about the in-device storage, it can be contested against as no infringement. The device also allows user to control the audio characteristics using a remote control which interacts with the device through infra-red. The Cru also allows the user to control the audio characteristics through a keypad on the device which could possibly infringe on the patent.

# 6,684,060 Digital wireless premises audio system

The patent describes a “home theater system incorporating the audio system”. The device performs the tasks which are quite similar to the functioning of the Cru such as transmitting songs wirelessly, decoding the song and play back on stereo. However, the device first encodes and audio signal while the Cru strictly works with mp3 songs which do not require any form of decoding. Another distinct difference is that the device uses Bluetooth protocol to transmit songs to the speakers while the Cru uses IEEE 802.11b protocol. Also since this patent deals with audio output, the audio standards used will also be a point to consider.

#6,684,060 System for playback of network audio material on demand

The patent describes a playback unit which retrieves songs from a remote server when requested by the user. Once the song is received from the server, the tasks performed by the Cru and the device is very similar. The difference however lies in retrieving the song to be played. The Cru receives songs from a user which is connected to the wireless network set up by itself while the device retrieves songs from a server on the basis of the user’s request. Also the Cru stores the songs on the on-board xD card in a queue and plays the songs in the order they were received. The device however streams the songs once they are retrieved from the network. This difference should be sufficient to avoid infringement of the patent.

Recommended Action to Avoid Infringement

As discussed under the analysis of the patents, there were no literal infringements on any of the patents. Although, there were possible infringements based on the doctrine of equivalents since some of the functions were performed roughly in the same manner. However, the functions which are performed similarly is the same for all devices which decode mp3 or other forms of encoded audio signals and play them back on stereo. This fact can be contested as also the fact that the Cru strictly adheres to IEEE 802.11b protocol for song transfer as against the wireless protocols described by the patents. If there are any infringements found with the Cru, then we can pay the fees to the authorities who hold the patent to avoid any future lawsuits.

4. Reliability and Safety Analysis

Reliability Analysis

The analysis of the device has been done for 106 hours of operation since that provides a large enough scale to ensure any non-reliability issues are detected well in time. We decided on a maximum failure probability of 10-5 for the Cru. This is an acceptable number since there is no chance of any physical hurt.

Rabbit 3000 Micro controller [1]

For the Rabbit 3000, we took it as a “MOS Device with > 6000 transistors”.

The failure rate is defined as

(p = (BD(MFG (T(CD + (BP(E(Q(PT + (EOS

Table 1

|Parameter |Value |Source |

|(BD |0.16 |(MIL-HDBK-217F, section 5-3)[1] |

|(MFG |2 |(MIL-HDBK-217F, section 5-3) |

|(T |0.98 |(MIL-HDBK-217F, section 5-8) |

|(CD |25 |Chip size 1.4 X 1.4 cm = 1.96 cm2 |

| | |Feature size 1 micron |

| | |(CD = ((A/.21) (2/Feat. Size)2(.64))+ .36 |

| | |(CD = ((1.96/.21)(2/1)2(.64))+ .36 |

| | |(MIL-HDBK-217F, section 5-10) |

|(BP |0.0044 |# of package pins – 128 |

| | |(BP = .0022 + ((1.72 x 10-5)(number of pins)) |

| | | |

| | |(MIL-HDBK-217F, section 5-3) |

|(E |2 |(MIL-HDBK-217F, section 5-10) |

|(Q |10 |(MIL-HDBK-217F, section 5-10) |

|(PT |6.1 |(MIL-HDBK-217F, section 5-10) |

|(EOS |0.065 |(MIL-HDBK-217F, section 5-10) |

(P = 0.16 * 2 * 0.98 * 25 + 0.0044 * 2 * 10 * 6.1 + 0.65

(P = 9.03 failures/ 106 hours

MTTF = 110,781 hours

STA013 MP3 Micro Controller [2]

“MOS Device”

(P = (C1(T + C2(E) (Q(L failures/106 hours

Table 2

|Parameter |Value |Source |

|C1 |0.14 |(MIL-HDBK-217F, section 5-1) |

|(T |3.1 |(MIL-HDBK-217F, section 5-8) |

|C2 |0.013 |(MIL-HDBK-217F, section 5-9) |

|(E |2.0 | (MIL-HDBK-217F, section 5-10) |

|(Q |10 |(MIL-HDBK-217F, section 5-10) |

|(L |1.0 |(MIL-HDBK-217F, section 5-10) |

(P = [(0.14 * 3.1) + (0.013 * 2.0)] * 10 * 1.0

(P = 6.94 failures/106 hours

MTTF = 1.44x105 Hours

Electrolytic Capacitors

“Capacitors, Fixed, Electrolytic”

(p = (b(CV(Q(E

Table 3

|Parameter |Value |Source |

|(b |0.013 |(MIL-HDBK-217F, section 5-15) |

|(CV (0.1uF, 10uF, |.21 |(MIL-HDBK-217F, section 5-15) |

|100uF) |0.49 | |

| |0.77 | |

|(E |2.0 | (MIL-HDBK-217F, section 5-15) |

|(Q |3.0 |(MIL-HDBK-217F, section 5-15) |

(p = 0.013 * .21 * 2 * 3

= 0.016 failures/106 hours for 0.1uF

MTTF = 6.25x107 Hours

(p = 0.013 * .49 * 2 * 3

= 0.038 failures/106 hours for 10uF

MTTF = 2.63x107 Hours

(p = 0.013 * .77 * 2 * 3

= 0.060 failures/106 hours for100uF

MTTF = 1.66x107 Hours

LM217 Voltage Regulator [8]

“Bi-polar Device”

(P = (C1(T + C2(E) (Q(L failures/106 hours

Table 4

|Parameter |Value |Source |

|C1 |0.02 |(MIL-HDBK-217F, section 5-1) |

|(T |180 |(MIL-HDBK-217F, section 5-8) |

|C2 |0.00022 |(MIL-HDBK-217F, section 5-9) |

|(E |2.0 | (MIL-HDBK-217F, section 5-10) |

|(Q |10 |(MIL-HDBK-217F, section 5-10) |

|(L |1.0 |(MIL-HDBK-217F, section 5-10) |

(P = [(0.02 * 180) + (0.00022 * 2.0)] * 10 * 1.0

(P = 3.6 failures/106 hours

MTTF = 2.8x105 Hours

Three of our most critical components (that are most likely to fail) are the Rabbit 3000 micro controller, the STA013 MP3 decoder chip, and the LM217 voltage regulators. Two other external components we could not find data on were the Keypad and the LCD. Failure of the LCD would result in a lack of information about songs and the device displayed to the user. In the event of a keypad failure, the user will not have the ability to control playback or obtain system settings.

The summary of preliminary failure rate calculations is listed below in Table 5.

Table 5: Preliminary Failure Rate Calculation

|Component |Description |(P |MTTF |

|N/A |Rabbit 3000 |9.03 |110,781 Hours |

|U17 |STA013 |6.94 |144,092.2 Hours |

|C |.1uF electrolytic Capacitor |0.016 |6.25x107 Hours |

|C |10uF electrolytic Capacitor |0.038 |2.63x107 Hours |

|C |100uF electrolytic Capacitor |0.060 |1.66x107 Hours |

|U13,14,15 |LM217 Voltage Regulator |3.6 |2.8x105 Hours |

Table 5 shows that the two components most likely to fail are the Rabbit 3000 micro controller and the STA013 MP3 decoder chip. The voltage regulators also have a low mean time to failure as compared to the rest of the components shown. For the voltage regulator this estimate could be pessimistic as we used the worst case junction temperature and did not take into account the use of any heat sinks in our device.

Failure Mode Effects and Criticality Analysis

In order to determine possible failures and the causes of those failures in our design, the cru has been broken into functional blocks.

Table 6: Criticality Levels for types of failures

|Class |Criticality |Description |Max Probability |

|Design Critical |HIGH |Incorrect Operation |10-8 per hour |

|Operation-Critical |MED |Incorrect or no information |10-6 per hour |

|Non-Critical |LOW |Minor inconvenience to user |10-4 per hour |

5. Ethical and Environmental Impact Analysis

Ethical Impact Analysis

There are some important ethical concerns regarding the development and usage of the Cru. As creators of the Cru, we are ethically responsible to create a product that meets the highest standards of quality and ensure that it does not cause any harm or grievance to the consumer, and if there are some issues as such, then they be well documented at least. The main ethical challenges can be broken up into the following main categories:

Testing

The Cru needs to be fully tested in a range of temperatures and operating conditions before it would be released into commercial production. The Cru will be tested for an average-case running operation time, i.e. an estimate of how long the device is powered on and functioning assuming normal, average load of operating. The condition most worth looking for is how hot any or all of the components get inside the stand-alone box, and whether the amount of heat generated a concern in regards to fire safety, i.e. whether the heat generated inside the box by any of components could cause an electrical fire. We will be installing air vents to ensure sufficient ventilation and once the product is fully integrated within its encasing, we will be testing whether those air vents are good enough or a small fan would be required to expedite heat dissipation.

The next step would be to ensure orientation issues. This entails making sure all the components inside the device are screwed on securely and under normal conditions of operations, they will not come loose and cause physical harm to either the product, or more importantly the consumer. This will ensure that the life of the product is maximized with normal wear and tear.

Warning Labels and Cautions in User Manual

The most clear ethical decision that needs to be made is to put warning labels on our device, especially regarding the power supply. There will be labels indicating the operating voltage and correct adapter usage. There will also be warnings telling the end user to not attempt to dismantle or troubleshoot the product since there are no user serviceable parts being used. All our components have been pre-programmed and packaged such that the device is working as-is, out of the box. Opening the device also might expose the novice user to electrical shock.

Not only will these warnings be on the device, but also explained further in the user manual. This will leave no room for ambiguity in understanding the limitations of usability of the product. The user manual will clearly explain how to set up the device, including temperature requirements and usage of the device to maximize product life. It will also indicate as to how to protect the device from direct sunlight, breakage, dust and water. Contact with water will short the device and render it permanently useless and it could also cause a fire.

Copyright Issues

The most important ethical dilemma is the usage of the mp3 standard for song playback which cannot ensure that there is no copyright infringement involved. Since the Cru is only a go-between to playing the music, it cannot be held directly responsible for abetting any possibly copyright infringement. However, we acknowledge that such an explanation is clearly not sufficient to excuse or condone any possible copyright issues regarding the usage of mp3 files. We will include a disclaimer and advisory in our user manual, recommending that users ensure the legality of the music they intend to play using the Cru. We feel that our users will exercise good judgment in their choice of music output and that they will ensure that they are the rightful owners of the music. The stealing of the music while it is in the queue is not quite possible, since the device will be, most probably, be monitored by someone, and the XD card that stores the music temporarily is embedded inside the packaging and not accessible by the user. Since we have purchased the mp3 chips we use, according to copyright information, we own the rights to using the mp3 codec algorithms, and hence that does not pose a problem.

Environmental Impact Analysis

As with the ethical impact analysis, the impact of the Cru on the environment has to be considered throughout the design and development process. The impact would be in the various stages of the Cru’s life cycle which includes manufacturing, regular use and disposal/recycling. Not addressing the environmental issues before the product is commercially introduced in the market would save money in the short term, however in the long run; there would be severe implications in the form of public litigation and lawsuits. Hence, the environment impact of the Cru must be closely examined and necessary precautions must be taken.

During the development and manufacturing of the Cru, several precautions need to be taken. The Cru can be designed to consume as little power as possible to function properly. Since the Cru is not battery powered and power consumption is not an issue, it is easy to design an inefficient device. However smart engineering and efficient use of resources can minimize needless wastage of power. In addition to this, a stand-by mode can be developed to reduce the power consumption by the Cru when idle. The Cru contains a PCB which generates a lot of industrial wastes [9] which cannot be completely avoided. Hence necessary precautions need to be taken which minimize the amount of wastes generated when the PCB for the Cru is manufactured. All throughout the manufacturing process, the EPA [10] regulations should be kept in mind and none of the guidelines should be flouted. Also while populating the PCB with the chips, lead free solder and non-ozone depleting de-fluxing chemicals should be used to mitigate the detrimental effects on environment.

The Cru would have minimal impact on the environment while in regular use since it does not emit any radiation or chemicals which could potentially be harmful. However, extra care will have to be taken when disposing/recycling the Cru since that will directly impact the environment. The LCD [3] will have to be disposed properly since they contain chemicals which are harmful to the environment. The PCB [4] also needs to be separately disposed because it has lead, copper and other heavy metals. In order to avoid these harmful chemicals coming in direct contact with the environment, necessary warning labels must be placed containing useful information of how to recycle/dispose the Cru with minimal harm to the environment. Additional information must be placed in the manual of the device for the user’s reference.

In conclusion, the numerous ethical and environmental impacts of the device must be addressed during the design and development process. Every device affects the environment and an ethical engineer must always make sure to notify the consumer of the proper ways of using and disposing the device in an environmental friendly manner. Addressing the ethical and environmental challenges can go a long way in making the device more durable and reliable.

6. Packaging Design Considerations

Analysis

Illustration and Description of Packaging Used.

Netgear MP101 [1]

[pic]

Fig 1. Netgear MP101

The MP101 is a television-independent receiver box with a built-in screen to beam MP3s around the house wirelessly to a Wi-Fi media receiver such as this Netgear box. The device measures 1.5 by 11 by 9 inches, with a four-line, 25-character LCD. The front face is silver, and the rest of the body is gray. The entire package is made of plastic (most likely PVC), which explains its low weight of 1.4lbs (0.62kg). It comes with a 37-button remote, and the rear has both standard RCA analog and headphone (1/8-inch) jacks.

Buttons on the remote allow one to access files by artist, album, and genre. It also allows the user to see a list of all available tracks. To jump quickly to the music one wants, tap out the first letters, cell-phone style, on the keypad.

Motorola Simplefi [12]

[pic]

Fig 2. Motorola Simplefi.

The Motorola Simplefi is also a digital audio receiver that makes it simple to play computer-based MP3 files and internet radio over a home stereo. Starting on the left it appears as a standard rectangular design and then transitions into a larger, more curved right side. The front of the 2 by 11 by 6 inch (HWD) package is silver and the rest is black. Much like it’s counterpart from Netgear, this device is made entirely out of plastic. Despite this, the device weighs in at a hefty 4.5lbs (2.1kg).

The Simplefi comes with a 12 button remote which allows for control of playback, volume and other useful features. This remote snaps in to the front of the device and serves as the face-plate-control. The Simplefi also comes with a 3-line LCD for displaying song information.

Discussion of positive and negative aspects of the product’s packaging:

Netgear MP101 [11]

Pros:

o Compact and sleek design (Fig 1)

o All in one package(no external peripherals required for connectivity)

o Easy to read, well placed LCD

o Multi-functional remote control

Cons:

o Wireless router or access point necessary for connectivity

o No local controls on machine without remote control unit

Motorola Simplefi [12]

Pros:

o Stylish curved contemporary design (Fig 2)

o Blue backlit LCD enhances overall look of product

o Remote Control snaps into device for face-plate control and storage

Cons:

o LCD screen is too small to read from more than a few feet away

o Much heavier than competing devices

o External peripherals required for device as well as PC for connectivity.

Aspects of commercial product’s packaging we plan to incorporate

o Both designs use a sleek look and we plan to use this idea in the final design of our own product.

o Netgear MP101 has a built-in wireless connectivity and we plan on incorporating a similar design (all-in-one approach).

o Our design will use a similar LCD placement as the Motorola Simplefi.

o Both the devices use a stylish silver plastic and we intend to utilize the same materials in our design.

Aspects of the CRU’s packaging that are unique.

o A keypad for on-board controls

o Status LEDs showing power on/off, reset and data transfer

o Rounded sides and no sharp corners for sleeker appearance

Materials List:

o Two 12”x12” sheet of PVC

o 4 rubber feet

o Screws and offsets of various dimensions

Tooling Required

We plan on having our main package manufactured by an outside plastics company. Hence the tooling requirements for that are not mentioned here because we are not totally aware of what they entail. However, some tooling will be required after the initial package is completed and received.

The following tooling will be required:

o A drill press to drill appropriate holes for a reset button, the three front LEDs, the power switch on back, and the array of holes needed for the fan (if necessary).

o A scroll saw or jig saw can be used to cut out the square holes needed to accommodate the USB drive, Keypad and the LCD.

Estimate of packaging weight and unit cost

Due to the choice of PVC as the main material for construction of the packaging, the packaging should not weigh more than 0.67 lbs total. Estimated cost of the packaging of the unit is around $23.00. A breakup of the individual component follows in Table 1.

|Components |Approximated Weight (in lbs) |Estimated Price (in $) |

|PVC Box |0.6 lbs |$20.00 |

|Rubber Feet (4) |0.02 lbs |$1.00 |

|Screws & offsets |0.05 lbs |$2.00 |

Table 1. Weight and Unit costs of individual packaging components

7. Schematic Design Considerations

RCM3360 [1] Rabbit Core Module:

The RCM3360 is a Core Module commercially available from Rabbit Semiconductors that meets our needs. The RCM3360 has 56 digital I/O pins which can be used for generic I/O as well as serial communications in a host of different combinations. This flexibility in I/O helped us finalize this processor core module for our project. The RCM3360 also has 512KB each of programmable flash and program RAM. This was important to us because we needed additional memory in our program to include the files necessary to host the http server for the web interface on the Cru. The main purpose of the RCM3360 is to act as a central communication unit which will bridge the TCP/IP information coming from the user to the USB host controller and then to bridge the host controller’s USB information to the mp3 decoder chip. In addition to making sure mp3 information gets downloaded, stored and played, the RCM3360 will also control a character LCD to display song information stored in the ID3 tag of the mp3 file and will control song playback via scanned input from a keypad encoder IC also present for final user input.

The RCM3360 operates at 3.3V and uses about 350mA of current. This will be by far the largest current draw by any single module in our design.

STA013 MP3 Decoder Chip:

The STA013 will be interfaced to the micro controller to decode the mp3 files transferred from the xD card and played out on stereo audio. The mp3 decoding is an integral part of the Cru. Without its functionality, the main purpose of our project would be impossible to achieve. The micro controller serially transmits mp3 files to the decoder via SPI. The STA013 will decode the mp3 files into the necessary digital format followed by a conversion from digital audio information to an analog audio signal that is output as a headphone line-level audio signal. This will be directly tied to the left and right phone jacks, which will finally be connected to the user’s stereo.

The STA013 has an internal clock running at the frequency of 24.576 MHz. It also has a serial clock coming in from the micro controller that controls the SPI. There is a separate I2C interface between the Rabbit and mp3 decoder for controlling the chip features which include play, skip, pause etc. The micro controller is also interfaced with the DREQ and DCLK pins of the mp3 decoder chip using parallel port pins. The DREQ allows the decoder to request data from the micro controller and DCLK is the serial input data clock signal coming from the micro controller. The STA013 requires 3.0V for its operation. Altogether, the device uses 55mA for normal operation.

DMC24201 [3] 24x2 Character LCD

The LCD will be used to display song and device information to the user. It requires an 8-bit data bus for instruction/data transmission from the micro controller. In addition, 3 control signals are used to control modes for the LCD module. The control signal includes pin VEE for contrast control, pin RS for input data/instruction select and pin R/W as data read/write interfaced with PE0, PE1 and PE3 respectively. Furthermore, there are codes to implement special functions such as clear screen, manipulate the cursor and shift display. The LCD screen operates at 5.0Vdc and uses ~ 5mA.

The LCD is an important part of our design. It will let the user know which song is playing, how much time is remaining in that particular song, as well as important device information (errors, IP address, etc.). It is the main link between the Cru and the user.

4X4 Keypad/EDE1144 [4] Keypad Encoder IC

While the LCD gives information to the user, the keypad and its accompanying encoder IC are the means by which the user can send commands to the Cru. The keypad encoder IC will take the information from the keypad and send it to the micro controller as 4-bit parallel data. The Encoder IC operates at 5.0V and uses ~ 1.8mA operating at a clock frequency of 4MHz.

The keypad is an important part of the Cru as it allows the user to input commands to perform many functions. Some of these important functions include scrolling through the play list, altering the order of the songs in the queue, skip to next song, retrieve device IP address, etc. Combined with the LCD, the keypad completes the user interface to the Cru.

Power Supply

The Cru is a stand alone digital wireless audio receiver which can be attached to a stereo to listen to the songs stored in the xD card. Since portability is not an issue, the Cru will not be battery powered. Instead, we plan to use a 12V dc wall-wart which can supply a 2A current to meet the power requirements of the Cru. We plan to use a Netgear wireless router to act as an access point for our Cru which requires a 12V dc and 800mA current supply. The LCD, Keypad and Encoder IC require 5V; the micro controller requires 3.3V and the STA013 audio mp3 decoder 3.0V. The total current requirement for the Rabbit processor and the various peripherals combined is less than 2A. For the purpose of regulating the wall-wart voltage supply and generate three separate voltages, we plan to use three LM217 [8] voltage regulator which can regulate voltages between 1.2 to 37V and current in excess of 1.5A. The nominal output voltage from the regulators can be selected by means of a simple resistor divider making our power supply easy to implement.

8. PCB Layout Design Considerations

PCB Layout Design Consideration

The CRU is not designed exclusively for portability; hence size is not a major issue for the PCB design considerations. The dimensions of our PCB layout are approximately 6.5” X 8.5”. The way we laid out our PCB was that we had the Rabbit headers in the middle and all the other chips - the MP3 decoders and the LCD and keypad headers around the central micro-controller pin headers for ease of use. This would also reduce the complexity of the wire routing.

Another major concern we needed to take into consideration when designing the PCB was wide-band noise from EMI sources. We have various digital clocks running in our circuit which generate the most digital noise. The most critical signals such as resets, interrupts and control line signals are the most vulnerable to noise interference from EMI transmissions. The easiest solution to this is avoiding orthogonal corners on our traces since ninety-degree angles generate excessive capacitance at the edges and disrupt the functioning of the circuit [13]. We are also implementing a low-EMI processor [1] that naturally lessens our concerns about interference and noise. Also, we have used a well defined ground system that helps us minimize noise voltage from currents flowing from ground impedance.

For our trace sizes, we use 40 mils for power and ground traces and 12 mils for the other traces [14]. We use high trace widths for power and ground such that we reduce heat build-up, especially during high current pulls. Hence, it seemed logical to use 40 mils traces for power and ground. For the regular traces, we felt that 12 mils would be a fair width to ensure signal reliability.

9. Software Design Considerations

The software design for the c|r|u was completely done using Dynamic C. During the first half of the semester, we used the Dynamic C 8.61 installed on the lab computers to progress on our software design. Later we migrated over to version 9.10 when we choose to use the on-board xD Card on the RCM 3360 core module in our design. The choice of Dynamic C was bound to the fact that we choose a Rabbit 3000 as the embedded microprocessor for our design. The ease of programming Dynamic C, which is quite similar to common C syntax made software design quite simple helping us concentrate of what to program rather than how to program.

Memory Models

The RCM 3360 module has a 512 K of program execution SRAM, 512 K of data SRAM and 512 K of flash memory [1]. The SRAM memory is used for compiling the program and running it in the SRAM helping us save burning the flash again and again. The data SRAM is also used for allocating memory to the program as and when required. If the design is not battery backed the data gets flushed out on power-cycle. The code is burnt to the flash once the final design is finished and device is required to perform the necessary operation on power-up. Having chosen a module with sufficient SRAM and flash space ensured that we have sufficient memory for accommodating the large HTTP libraries required by our design.

Startup Code

As with any embedded system, all our peripherals need to be initialized on start up in the correct order.

The correct order of initialization is: Initializing the HTTP_Handler, followed by setting up the FAT file system on the xD Card and then register the mounted partition with the zserver to upload files to using an ordinary web browser. Once this is done, the Mp3 chip is initialized, the keypad interrupts vectors are setup and finally the LCD is initialized and displays the welcome message signaling that initialization sequence has ended and the c|r|u is ready to be used.

Organization of Embedded Code

For the purpose of modular software design, we organized the software for each of our design components as separate libraries that could be imported easily using the “#use” directive. This made the code much more readable and increased the ease of debugging the software manifold.

Software Design Narrative

LCD Module

The LCD is used to display useful information such as the current song title and artist’s name during song playback. At other times, it also displays other information to inform the user of the device’s status at any given point of time. The LCD uses an 8-bit parallel data bus interface on Port G to hook up to our microprocessor. 3 other port pins are used on the processor to control the functioning of the LCD. PE1, PE3 and PF0 are used for controlling the R/W, EN and the RS port pins of the LCD respectively. The characters are sent to the LCD one at a time and get decoded by the inbuilt controller and are appropriately displayed on the LCD screen.

Keypad Encoder

The Keypad Encoder IC uses a 4 bit parallel interface to transfer key press information to the processor. A single bit line called the Valid_Data generates an external interrupt to the processor on pin PE0 when the key press has been encoded and valid data is available on the port pins for the processor to read. The ISR asserts a flag stating that a Button has been pressed and buffers the port values for the program to read and perform the necessary action.

STA013Mp3 Chip

The STA013 mp3 chip uses two different interfaces for its proper functioning. The commands like play, mute, soft reset are sent to the chip over an I2C interface with pull up resistors on port PD6 and PD7 to act as the SDA and the SCLK clock line. The mp3 data stream itself uses a SPI mechanism to send data over to the chip which it then processes and send to the DAC converter for stereo level output. Port PC2 is used for the serial data line and the port PF1 provides the serial clock.

Onboard xD Card Storage

The xD card(by Olympus) is formatted with a FAT system which makes reading and writing Mp3 files easy. Using Dynamic C’s Fat library system, the effort required in communicating with device required minimal understanding of control signals involved. Hence, no more details can be provided about this module.

[pic]

10. Version 2 Changes

For our second iteration changes there are a few steps we would take to improve the hardware and software performance of the Cru. The first of which is to write all of the serial communication routines in assembly in order to facilitate smoother music playback. For the Rabbit processors, assembly programming runs much faster and is much simpler than that which is written in C. The next Change would involve optimizing our board layout to facilitate a smaller board which could fit into a smaller device in general. One more step to communicating more efficiently with the MP3 decoder could be to use a parallel to serial shift register which would allow the processor to write whole bytes at time and facilitate faster communication. A better planned and sleeker looking package would be used in conjunction with our smaller PCB. This would give the Cru more commercial appeal. Finally we would like to add additional control features to the playback and the device in general, including volume, bass and treble etc.

Summary and Conclusions

At the conclusion of our time working on this project, a whole host of skills were acquired by all of the members of the wrecking cru. Most importantly, the process of bringing a product from conception all the way to implementation was learned. In addition, skills in soldering, board layout, realistic schematic design and component selection rationale were acquired by all members of the team. Finally, documentation was a huge part of this class and the process of designing and building a working product. All team members became well acquainted with the amount and types of documentation necessary to successfully complete the project. Many skills involved in real world design were encountered and mastered in the process of completing this project.

References

[1] Rabbit Semiconductor (Rabbit 3100 micro-controller)



[2] STA013 MP3 Decoder Chip



[3] DMC 24201 LCD Screen:



[4] EDE1144 Keypad Encoder IC:



[5] Motorola MC68HC912B32:



[6] ATMEL AVR ATmega64:



[7] VLSI VS1001k MP3 CODEC:



[8] LM217Regulator



[9] Military Handbook (Reliability Prediction of Electronic Equipment)

Department of Defense

Washington DC 20301



[10] Designing for Reliability Maintainability, and Safety

George Novacek



[11] Netgear MP101



[12] Motorola Simplefi



[13] System Design and Layout Techniques for Noise Reduction in MCU-Based Systems AN1259, Motorola Semiconductor Application Note



[14] ECE 477, Purdue University, Homework 2 Guidelines, Fall ‘04

[15] Dynamic C TCP/IP user’s manual



[16] Dynamic C User’s manual



Appendix A: Individual Contributions

Contributions of Mohnish Rathi:

At the beginning of the semester, I participated in our brain-storming sessions while coming up with the project idea and also conceptualizing the working of the Cru. My other main responsibility was to work on our schematic and the hardware aspect of the project. In retrospect, working with on this project has taught me many technical and non-technical aspect of electrical engineering. From a technical standpoint, I got to learn about making a schematic for a project, PCB layout, power supply and interfacing of a micro-processor with various peripherals. From a non-technical point of view, I got an opportunity to conceptualize my own idea and work towards the successful implementation of the idea. Also getting a chance to work with such a brilliant and diverse group (two computer engineers and two electrical engineers) was a lot of fun.

As an electrical engineer, I could not contribute much towards the software, but I helped Sumit and Pranav, with however much I could, with my knowledge of assembly level programming and interfacing of peripherals with our Rabbit micro-processor. I worked with the group in making our LCD and keypad work. I also worked with Sumit on the I2C protocol which our MP3 chip uses to communicate with the Rabbit. All throughout the debugging stage, I was called upon to use the logic analyzers, oscilloscopes and other equipments to check for the correct implementation of our code. The logic analyzer was a big help while we prototyped our LCD module and tested I2C protocol.

I was responsible for making the schematic of the Cru and I successfully completed the job. I also put in many hours on our PCB layout which required extra effort since we had to interface our micro-processor with two mp3 decoder chips. It was my idea to include the two mp3 chips in our board layout along with the USB host controller because that would give us a back-up option of reverting to the chips which we could get to work. In retrospect, that was a very good idea because beginning of the semester, we started off with prototyping the VLSI1001K chip but we ended up using the STA013 chip since it was easy to use and had a lot of documentation available.

I also helped Brandon with the power supply and packaging of the Cru. I was working with a voltage regulator for the first time and it did not seem too difficult to understand. Working on the packaging was fun since we had to creatively come up with a design for the Cru. We worked in Brandon’s garage and the presence of extensive tools helped us immensely. Apart from this, I was also responsible for the patent liability analysis homework which required me to spend a lot of time at the website of the US Patent Office.

From the start to finish, our group worked on all aspects of the project as a team. Even though we were individually responsible for many of the homework, we would always work together. All of us were an integral part in the development process of the Cru right from its conceptualization till its completion. Our project met the design outcome criteria and because of my contribution and participation, I feel that I deserve at least a B for my senior design project.

Contributions of Brandon Fane:

Being one of two Electrical Engineers in the group, I thought that I would have little to contribute to the group. This assumption was quickly proven wrong. Although I had little knowledge of software, this project required much work in the areas of circuit design, power supply designs, packaging and a whole host of other tasks.

The first of my contributions was parts selection and purchasing. I found myself in the role of technical buyer. Having the most previous experience building electronics projects, I was put in charge of picking out the LCD, keypad, and voltage regulators. I also had input in the choice of mp3 chip, USB host controller and the microprocessor we chose to use. Once these parts were chosen, it was my job to contact manufacturers and distributors to buy the parts or acquire samples. This turned out to be quite an undertaking, since many of our major parts came from different businesses.

Once the parts were purchased and on their way, power supply considerations needed to be taken into account if our project was to operate on its own power supply. I chose the “wall-wart” we would use and picked out the voltage regulators we needed. I was in charge of setting the correct resistor values that would set our adjustable regulators to the correct output voltage.

I also did the majority of the fabricating for our packaging. I had the most experience with construction and I owned the most tools and had a garage in which we could use them. Once the packaging was built, I chose the power indicator, the power switch and connector. I also chose the audio jack to use for the output of the device.

My final physical contribution involved creating the adapters that would allow the LCD and keypad to connect to our PCB. The Devices all came with their individual methods and types of connectors and this created a problem since our PCB was designed and sent to be manufactured before we really knew how everything should be connected. I created adapters that would allow a uniform use of 0.1 inch headers on our board and still allow all the off-board devices to connect easily in this manner.

In addition of these duties, I helped with Schematic and PCB design with the rest of the group. These tasks along with homework kept me more than busy throughout the course of the semester. Due to the amount of effort put forth and the fact that the device demonstrated all five of our success criteria, I feel I deserve at least a B in this course.

Contributions of Sumit Mehra:

This is my attempt to summarize my individual contributions to CRU project. The semester obviously started off with individual ideas bouncing back and forth about projects that we could feasibly attain in one semester. I came up with ideas of advanced house security systems and few others. Once we choose Brandon’s idea of going with the wireless Mp3 audio receiver, I played an active role in deciding what will the device do and what parts will be easy to interface to a processor to get our design to work.

Once we choose a design and needed lab notebooks for documenting our project progress, I helped Pranav set them up so that the blogger could easily do the formatting task for us. Having known for a fact that I was predominantly going to play a major role in the software design I started out the semester with looking for possible choice of processors along with Brandon to be used for our design. Once we decided to go with a Rabbit 3000 series processor early on during the semester, I started browsing through the manuals to get an early feeling of the instruction sets available for the Rabbit and how easy was to write a program in Dynamic C and get it compiled and running on the rabbit.

As we started receiving our parts, I started prototyping with the LCD and wrote chunks of code to get characters displayed on our LCD. Being able to read timing diagrams from ECE362 did come in very handy as we hooked our LCD up to a logic analyzer for debugging purposes. Once we realized the mistake I was making with our start up initialization for the LCD, I fixed it up in a jiffy and got our LCD up and running.

The next item on the agenda was to get the Keypad inputs to work. Once Brandon hooked up the keypad to our processor headers, it was only a few minutes of looking through the external interrupt sample that I had our keypad values being printed on the stdio window. I was also responsible and worked a lot on the PCB layout for our design, with a lot of help from my teammates.

My next contribution to the team was to decide on an easier way to store Mp3 on an on board xD-Card that I found on the RCM3360 module on Rabbit’s website. On my recommendation on how hard it’s going to be to interface a USB to the processor via a controller, the team decided to go with the idea of the on board xD Card.

While waiting for the new processor, I started working on getting mp3 files over to the processor and storing them to the flash. I basically edited snippets of code that I found in the samples directory to get Mp3 upload to work. I also played an important role in suggesting that we should use a FAT file system for storing our Mp3s’ as it’ll make reading and writing files so much easier.

The next thing that I worked on was the heart of our device, the mp3 chip. This was the last and most time costly piece of component that I worked on. It took me about a month’s worth of work to program this device; ironically the code was not more than twenty lines long. This was partially due to the reason that we worked with a burnt chip for two weeks. Once we I finished prototyping with the chip and got music playing on our device, I integrated the xD Card as our storage device to store bigger mp3 files and organized the code into modular library files that could be easily imported in any C file.

Once all this was accomplished, I wrote the code to integrate all our modules and get them working together. Once this was accomplished, our project was done and all this obviously was accomplished with a lot of help and contribution of the whole team effort.

Contributions of Pranav Kabra:

Throughout the semester, I was involved in various aspects of the development and creation of our project, the cru. As the semester began, and we had to come up with the idea for our project, I applied a lot of thought to come up with the concept of the cru, based on my own past experiences that, along with collective brainstorming with the team, devised the final project proposal. I was the chosen team leader of the Wrecking Cru (the Team 9 pseudonym), and I took it upon myself to derive the initial functioning of the cru, like the components needed and the interfacing of the various peripherals that we would use.

We were an excellent team, in terms of our group dynamics, where we worked very well with each other, and each of us was given equal importance and allowed input in all parts of the project. We all insisted that no matter what part of the project we worked on, software or hardware, we would all work on it together. No one was let feel inferior or put in the back seat, and that led to our collective bonding, that would eventually drive us to complete building the cru.

To flag off the project, I created our website, creating our distinct style and feel to the group. I also came upon the idea of using third-party software for our notebooks, the Blogger service, integrated on our website. Throughout the semester, I was in charge of updating the website as we got more documents. I and the team also worked tirelessly to create our project proposal, weighing out features we could achieve. I feel I played an important role in deciding which components we should use and how they would function in our final project. Even though we always functioned as a team, as opposed to simply individual components, we all played important roles in almost every aspect of the development of the cru. Every week, we met in lab 5-6 days a week, averaging 5 hours a day, researching components, and their usefulness to our project, along with the degree of usability to us. The team and I collectively decided on using the Rabbit 3300 module, which we later decided to change to the 3360 module, and our MP3 chip, key components of our design.

I contributed on all homeworks, and so did the rest of the team. Even though, the homeworks were responsibility of one team member every week, we decided to function as a team, and all contribute on the homeworks. I personally spent many hours on the component selection homework as well as the PCB design layout. It was my responsibility to do the software analysis as well as the ethical and environmental impact. I wrote almost the entire manual, something that gave me great insight into the world of good technical writing. I and Brandon worked very hard on the packaging, trying to figure out the best style and as well as the best functionality for the final package. I was responsible for our presentations, both mid term and final, as well as the main speaker. I also wrote a significant portion of all our reports.

On the project itself, I had contributions in all departments. I began the process of writing our code, especially when we were trying to get the HTTP handler to work on the rabbit to host a webpage. Though later, Sumit took over the role of chief software architect, I, as a computer engineer, felt it my responsibility to propose ideas as well help in some debugging whenever we hit roadblocks. Like Mohnish, Brandon and Sumit, I too did a lot of PCB layout along with the schematic design, which was slightly tedious, since I wanted to ensure that the internal wiring should be neat and tidy. I assisted our 2 Electrical Engineers, Mohnish and Brandon, in hardware testing, and even though I could not be as proficient in debugging as them, I was definitely important to the process of testing all our hardware. I helped Brandon in the wiring of some of our equipment as well.

I am very proud of the cru, and I am very proud of our group. We were truly the definition of a team, always working together, and helping each other out whenever one of us could not complete a particular design process. We were always willing to listen to each other, and this collectively led to a harmonious relationship and in the end, the successful completion of our project. I am also proud of my contribution, as well those of all the others, and I feel I deserve an A in this Senior Design Course.

Appendix B: Packaging

[pic]

Fig. B-1 front, back and side view of the c|r|u

[pic]

Fig. B-2 Actual product front view of the c|r|u

Appendix C: Schematic

[pic]

Fig. C-1 Overall Schematic for the c|r|u

Appendix D: PCB Layout Top and Bottom Copper

[pic]

Fig. D-1 PCB Layout Top Copper Layer

[pic]

Fig D-2 PCB Layout Bottom Copper Layer

Appendix E: Parts List Spreadsheet

|Part |Part Number |Vendor |Quantity |Price |Total Price | |

|Description | | | | | | |

| |

|A: Power Supply ( Regulators, Capacitors) |

| | | | | | | |

|A1 |No supply voltage |Bad regulator, shorted ripple capacitors, |Device does not operate at all. |Observation |High | |

| | |bad adjustment resistors. | | | | |

| | | | | | | |

|A2 |VCC_5 not 5V |Bad adjustment, bad regulators |Overheating of device, | | | |

| |VCC_3 not 3V | |unpredictable device operation, |Observation |High | |

| |VCC_3.3 not 3.3V | |damage to components. | | | |

| |

|B: Micro-Processor (Rabbit 3000) |

| | | | | | | |

|B1 |Random Output |Damaged Processor, Software Error |Unpredictable operation of |Observation |High | |

| | | |peripherals. | | | |

| |Doesn’t recognize keypad | | | | | |

|B2 |interrupts |Damaged Processor |Incorrect operation of device. |Observation |Med | |

|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |

| |

|C: Peripherals (LCD, Keypad, Pushbutton, Status LED) |

| |LCD not working |LCD disconnected, Damaged, Software error |No display of information | | | |

|C1 | | | |Observation |Med | |

| |Keypad not working |Keypad disconnected, Buttons damaged / | | | | |

|C2 | |stuck, Software error. |No control over device |Observation |Med | |

| |Pushbutton not working |Pushbutton disconnected/damaged/stuck, | | | | |

|C3 | |Software error |No control over device |Observation |Med | |

| |Status LEDs not lighting |LED disconnected/damaged, Software error |Device status information not | | | |

|C4 |up | |available. |Observation |Med | |

| |

|D: MP3 Decoder / DAC |

| | |Damaged mp3 chip, Faulty connection, | | | | |

|D1 |No audio output |Oscillator failure, Incorrect data |No audio output |Observation |Med | |

| | | | | | | |

|D2 |Audio output noisy |Damaged DAC, |Noisy audio output |Observation |Low | |

| | |Faulty connection. | | | | |

-----------------------

Retrieve file

Comments:

Yes

Send To Storage

UploadingMP3 File?

Init_MP3chip

Send to MP3 playback

Send ID3 to LCD

Init_LCD

Welcome Screen

Init_HTTP

START

Play pressed?

Y

End of song or Stop?

Clear MP3 and Reset

Y

No

HTTP Handler for Uploading MP3

No

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download