• Concept
• Motivation
• Competition
• Tech Specs
• Requirements
• Architecture
• Use Cases
• System States
• Error Handling
• Implementation
• Test Cases
• Evaluation
• Lessons
• Fun Stuff
• References
• 18-549 Home

MEMBERS

Yoojin Kwak Mike Preysman Ruben Quintero Russell Savage

PROJECT CONCEPT

This project will provide a portable communication device for use within an industrial, collaborative work environment.

Using personal headsets, users will be able to send audio and visual messages to groups or individuals across an 802.11 network environment. The system will integrate various components including: wireless nodes, headsets devices, and potentially a base station.

MOTIVATION

When repairing nuclear facilities, teams of engineers are required to wear tethered headset devices for communication due to constraints of broadcast radio. The tether system not only hinders mobility, but is also time consuming to set up and maintain. Our wireless solution will provide cordless communication, expanded visual and network features, and easy integration into desktop environments. It can be used as a wireless alternative for nuclear repair teams, as well as a scalable communication system for other working environments

COMPETITIVE ANALYSIS

• Walkie Talkies - Wikipedia article -
  

  Walkie Talkies are a standard method of wireless communication and have been used in areas such as entertainment and industry. While they are less expensive, they are limited to 500 mw of effective rf power, limiting both the range and strength of signals used for communication, and are usually only two way.
  
  
  

• Tethered communication device -

  Tethered communication devices are what are currently being used in areas such as nuclear facilities where environmental constraints make broadcast radio ineffective. While you never have to worry about losing a signal, tethered communication devices limits mobility and range, and are not timely to set up and maintain.
  
  
  

• Camera Phone -

  Camera cellular phones are currently being used to transmit audio and visual data. While they are compact and widely available, their range is also limited under the constraints we are working in, and the user interface is not ideal for working conditions, where a user might need both hands.

TECHNICAL SPECIFICATIONS

Hardware:

• Headset
• Camera
• Personal Communication Device
• Wireless Repeaters
• Base Station
• Wireless Router

Software:

• Java for transmitting voice through the internet
• Speex (Jspeex) for encoding and decoding voice

Protocols:

• 802.11
• Speex

REQUIREMENTS

Functional Requirements:

• Accepts audio and visual input into the personal devices.
• Transmits data across a secure 802.11 network.
• Outputs received audio data to the personal user.
• Must be able to support at least 10 users.
• Allows for a base station to manage users and communication in adaptable groups.
• Outputs received visual data at the base station.

Non-Functional Requirements:

• Simple user interface with large accessible buttons.
• Latency between speaking and hearing between users should be less than half a second.
• Seamless connectivity while traveling between wireless nodes
• Devices work for a period of at least three hours (including battery life) and weigh less than three pounds.
• Data must be reliably processed so that all conversations are coherent.

ARCHITECTURE

Basic Architecture

Detailed Architecture

USE CASES (INTERACTION DIAGRAMS)

User Use Case

• Set up system
• Receive from users
• Establish groups
• Add User
• Remove User
• Tear down system
• Query group info

Base Station Use Case

• Listen
• Send to group
• Send to base Station
• Request to join group
• Request to leave group
• Request to send-all
• Query group info

Risks & Risk Mitigation

Risks

• Major Risks centered around Network
  • Network Traffic
  
  How much bandwidth/users
  • Latency
  
  Back and forth between base station
  • Packet Loss
  
  Impact on overlaying signals
  • Interference
  
  Potential obstacles, etc.
  • Seamlessness
  
  Packet transition between different nodes.


• Hardware - Hardware failure & incompatibility



• Software - Software bugs



• Usability

Risk Mitigation

• Fundamental Risks
  • Must be able to seamlessly have a conversation
  • Packet loss cannot be an issue
  • Latency must be below .5 seconds


• Ancillary risks
  • Nice to have > 10 users
  • No hardware issues will be supported

SYSTEM STATES & TRANSITIONS

User Use Case

Base Station Use Case

ERROR HANDLING

The base station sets a timeout for each gumstix to detect if it has been disconnected regardless of the cause.

-Disconnected users are stored so that their information is recoverable on reconnect.

If the base station fails, the gumstix will try to reconnect continuously.

IMPLEMENTATION DETAILS

• Base Station
  • -Each gumstix is set up as a User and placed in a Group
  • -Each User thread handles the reading/writing to the sockets.
  • -Grabs the audio stream from the gumstix, and sends this data out to the correct group.
  • -Handles the UI/sends to speaker
  • -Allows for dynamic group management.
• Gumstix
  • -Implemented on a Linux base.
  • -Setup as a client to send data to the server.
  • -Setup as an individual server to receive audio from members in their group routed through the Base Station
  • - Gets the input/ouput from piped from an OSS Simulator.

• Fundamental Risks
  • Gumstix Boot
  • Device launches application, tries to connect to Base Station
  • Base station adds Device to default group, starts sending audio


• Gumstix Disconnect
  • Gumstix kills any connection stream it has
  • Base Station changes user status to 'inactive' and kills any connection it has


• Group Change
  • Base station changes the user's group
  • Gumstix can now hear/send audio only to/from members of their new group

EXPERIMENTAL EVALUATION

• Distance vs Ping time and Packet Loss
  • Why: In normal operation, the gumstix will be far away from the base station. We want to test the gumstix under these conditions
  • How: We will 'ping' the gumstix as the gumstix is moved away by increments of five feet. We will note the ping times and packet loss.


• Number of users vs Ping time and Packet Loss
  • Why: To see how many users a base station can handle while still being functional.
  • How: Increase the number of users and repeat a 'ping' and record the times and the packet loss


• Buffer Size
  • Why: Changing the buffer size changes how well a user hears the audio. We wish to find the ideal packet size.
  • While keeping everything else constant, change buffer size to and user human intervention to determine which buffer size results in the most coherent audio.

LESSONS LEARNED

• Conduct more research/talk to professionals before starting to code.
• Gumstix hardware is a fickle, fickle thing
• Expected problems i.e. network lag is not always the problem. Sometimes unforseen errors can occur

FUN STUFF

We're not fun.

REFERENCES

• Project Proposal and Requirements, Team Project Presentation, January 31, 2007
• Design & Architecture, Team Project Presentation, February 14, 2007
• Mid-semester Project Status, Team Project Presentation, Date TBD
• Test Plan & Experimental Validation Team Project Presentation, March 28, 2007
• What's Done, What's Left Team Project Presentation, April 11, 2007
• Final Project Presentation, Team Project Presentation, Date TBD
• Project Poster, May 4, 2007