DOC PREVIEW
MIT 6 111 - Study Notes

This preview shows page 1 out of 3 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Brian SchmidtMatt Welsh 6.111 Final Project ProposalAs broadband internet access begins to pervade American households, traditional phonelines are being replaced with a new technology called VoIP which is short for Voice overInternet Protocol. While some VoIP implementations require users to place calls throughtheir computer (such as Skype), others allow the user to place calls using phones similar infunction to traditional analog phones. Although time constraints prevent us from developinga fully functional VoIP phone system, we would like to develop a similar system for our finalproject. Our system will still be able to connect to the internet and transmit voice data,but it will not adhere to the VoIP standard and thus will be unable to communicate withcertified VoIP systems.VoIP is not itself a protocol as are IP or TCP. VoIP refers to a collection of protocols, allof which are designed to transmit voice over IP-based networks. These VoIP protocols areat the top of a stack of protocols used to implement IP-based networks which are routinelydescribed through the 7-level OSI Model. Level 1 of this model consists of the physicalwires used to connect network nodes, while level 7 consists of application proto cols such asthose that fall under VoIP. To simplify our development process, we plan to use a wirelessnetwork adapter to handle levels 1 and 2 of the OSI model (the physical and data link layers,respectively). In order to connect to the internet, however, we plan to implement handlingof the IPv4 protocol (level 3) so that our device may send and receive data over the internet.The general block diagram of our system is shown in Figure 1.WirelessLANControllerPhoneControlsAudio Encoder/DecoderInternetProtocolHandlerMicrophoneHeadphonesInternetBrianMattBrianFigure 1: Project Block DiagramThe inputs to our system will consist of audio input from a microphone via the AC97 chip,buttons for user input, and data packets from the network. We will use an audio encoderto compress the audio data before transmitting it over the network, and a complementaryaudio decoder to decompress the audio data once it is received from another phone.The outputs of our system will consist of audio output to the headphones via the AC97chip, lights to indicate connection status, and data output from the wireless LAN adapter.1Brian SchmidtMatt Welsh 6.111 Final Project ProposalTesting of the wireless controller will be done using a network analyzer to listen to andvalidate the data packets being sent to and from the controller. Since we will be usinga third party wireless network adapter and most of the work will be put into writing theinterface and drivers for the controller, simulation will play a key role in the testing of thewireless network adapter. All of the interface drivers will be tested by running simulationsand comparing the data to the expected results based on network specifications before beingtested in the field.Wireless Network AdapterThis module describes both the physical adapter and the drivers used to control it. In ouroriginal design, we planned to use wired ethernet, and an open source ethernet controllerwritten in verilog. Instead, we have decided to pursue a wireless design, to facilitate ease ofuse. We hope to receive funding in order to purchase two wireless network adapters, for usein our project. We will then acquire data specifications for the devices, and write driverswhich will interface with the controllers. After researching wireless protocols, we have foundthat using a third party adapter and writing our own drivers will prove to be a more thanadequate digital design challenge. There are many layers of protocols that exist on top ofthe networking controller, and this module will sort through them to make sure the data issent and received properly over our two wireless network controllers.Brian will be responsible for implementing the wireless network adapter interface.Phone ControlsThis module will contain all of the actual user interfaces. There will be buttons to both callthe other user, and to accept an incoming call. It will have a microphone as an input, andheadphones as an output. The user will also be able to view the call status and networkactivity on the labkits LEDs.Brian will be responsible for implementing the phone controls module.Audio Encoder/DecoderInitially, our Audio Encoder/Decoder will be a simple sampling of PCM data produced bythe labkit’s AC97 chip. The sampling rate will be chosen to be compatible with the limitwe’re able to transmit and receive data to and from the wireless network controller. If timepermits, we hope to implement either the G.711 codec or the more complex G.729 codecwhich are both commonly used for VoIP.We plan to test our encoder/decoder by feeding audio data from a microphone to theencoder, passing the enco der’s data through the decoder, and then listening to the resultthrough a speaker or headphones. This ensures that any data we send to another phone willbe able to produce an intelligible voice signal.2Brian SchmidtMatt Welsh 6.111 Final Project ProposalIP HandlerThe IP Handler will convert audio information from the audio codec module into packets tobe sent over the network as well as convert packets received from the internet into compressedaudio data to be sent to the audio codec. In addition, it will handle signals to and from thephone controls such as establishing a connection, disconnecting, and indicating connectionstatus.We may test the IP Handler by storing its output to memory on the 6.111 Labkit andthen sending the data back through the handler as if it were receiving the data from anotherphone. This circumvents the wireless network controller, so that the IP handler may betested indep endently. If the received signals produced the desired output in the phone andthe expected audio signals, we will know that the module is working.Because the IP protocol is a standard and widely-used protocol, we may consider analyz-ing the data send from the labkit on a computer with a wireless connection once the wirelessnetwork adapter is functional. This may be done using a packet sniffer or network analyzeron the computer with the wireless connection.Matt will be responsible for implementing the IP handler module.While this project may seem complex overall, we feel that the complexities are manage-able, and that we will be able to produce a functional system in the time


View Full Document

MIT 6 111 - Study Notes

Documents in this Course
Verilog

Verilog

21 pages

Video

Video

28 pages

Bass Hero

Bass Hero

17 pages

Deep 3D

Deep 3D

12 pages

SERPENT

SERPENT

8 pages

Vertex

Vertex

92 pages

Vertex

Vertex

4 pages

Snapshot

Snapshot

15 pages

Memories

Memories

42 pages

Deep3D

Deep3D

60 pages

Design

Design

2 pages

Frogger

Frogger

11 pages

SkiFree

SkiFree

81 pages

Vertex

Vertex

10 pages

EXPRESS

EXPRESS

2 pages

Labyrinth

Labyrinth

81 pages

Load more
Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?