Group interactions

Also, has anybody written the group interactions section yet? Can one of you guys do that. I'm exhausted so I'm going to go to bed now. I'm gonna wake up in the morning to do the proofreading. I've assembled the design document into one file and we're doing pretty good on length and from what I've read I think we're mostly okay.

Social impacts

Here's the part I hadn't written yet:

Broader Impacts

What impacts does your design have on organizations, and society, including ethical, legal, security, economic, environmental, and global policy issues.

Our design primarily targets the consumer product market in the form of wireless audio input and output devices. Another potential application could include military use as a means for soldiers to communicate with one another. Alternatively, the design could be used in the space program as a means for planetary rovers to communicate across long distances with each other via our design’s mesh networking capabilities. Ethically speaking the design should not be problematic. Legal problems could surface around the Zigbee protocol, but that is beyond our control. On our end, all parts going into the design are off-the-shelf components running according to specification. At present our design does not include extra steps towards security precautions, and consequently devices running off of our design should not be used where security is a concern. Our design is unlikely to have broad economic, environmental or global policy effects.

My contribution

These are a work in progress.

Motivation/Background

Consider a group of bicyclists who want to build team spirit by playing a group song while riding. One way to play music that each rider can hear is to have one cyclist carry a speaker large enough to project the music to everybody. This is an inconvenient solution for the rider carrying the speaker system, and further, this is an impractical solution since the volume of the music is dependent on distance to the source.

Project Goal

Consider an alternative where each bike carries a small speaker, thereby eliminating the need for one loud central hub. Each of these speakers will wirelessly receive streaming audio from a central source, thus enabling each rider to hear the music equally well regardless of distance. Ultimately, one person should be able to hook up a music player to this streaming device, and every rider on the network will be able to receive and play back the streaming audio in a synchronous manner.

System Specification

The network will consist of a broadcaster and listeners. The broadcaster will take advantage of an audio jack which can receive music or other audio from a commercial music or audio player. The music data from the input jack will be streamed over the network to the listeners. The listeners will be able to receive the streamed audio and both the listeners and the broadcaster will be able to play the audio from their speakers.

User Scenarios

· As mentioned in the motivation for doing this project, consider a case where one person would like to set up his or her own personal radio station that his or her friends can tune into, but is maybe in a place not nearby computers (bike riding, hiking, etc.)

· Somebody would like to throw a party and would like to avoid disturbing the neighbors. Rather than have one enormously loud music source to reach the whole party, the music sources can be wirelessly distributed around the house/apartment/etc. to allow each speaker to play quieter but still enable partygoers to hear the music. Wireless connection is a plus because there are no wires to trip on and you know how parties can go.

· Consider a family who is about to eat dinner, but everybody is in their rooms. Rather than shout, an announcement can be made via microphone that dinner is ready. This way, if everybody has a speaker in their room, they will hear the dinner announcement and nobody will have a hoarse voice.

· A bunch of people are playing paintball in teams and would like to communicate with each other covertly. Each person can carry one of these devices and communicate with his or her teammates remotely.

Evaluation Criteria

· Does it work?

· Synchronous playback

· Quality of sound

· Power consumption (i.e. will this drain your batteries too quickly)

· Transmission range

· Reliability, packet loss, etc.

· Cost efficiency

· Weight and size

· Color (pinker is better)

· Compatibility with existing consumer products

· Interference with other consumer products

· Ease of setup

Test Plan

You should describe how you intend to test each major component and how
you intend to test the system as a whole. The order in which components
will be tested should be presented. You should justify why your testing
procedures and ordering are sufficient.

The main components of our project are a battery pack, an 8051
microcontroller, an XBee Zigbee radio chip, an analog-to-digital
converter, and a digital-to-analog converter. Each unit will have an
analog input, an analog output, and a power switch.

We will ensure proper connection to and operation of our battery pack with
a multimeter. Subsequent failure of the battery pack should be
immediately apparent during the course of regular testing (i.e. things
won't turn on). As the system nears completion, we will have an idea of the battery life that our pack provides.

When testing our microcontroller, we will first test that we can burn a
simple program into our microcontroller, such as a program that
turns on an LED. When writing programs for our microcontroller, we will
ensure that the programs run on a suitable microcontroller emulator. After we have verified correct operation on the emulated microcontroller, we will burn the program to the real microcontroller and subsequently verify correct operation there. Once burning simple programs to the microcontroller becomes trivial, we will shift our attention towards more complicated microcontroller programming.

For testing our XBee Zigbee radio, we will begin with two XBee chips. We
will designate one chip as the broadcaster and one chip as the receiver.
For a simple send/receive test, we will tell the broadcaster to send a
trigger that will command the receiver to turn on an LED. After we are
able to send simple commands from one chip to another, we will try
streaming packets from the broadcaster to the receiver to ensure that we
are able to maintain a steady data rate between the two chips. In addition, we will test the range of chips. Further, we will test mesh functionality across multiple Xbee units.

Testing of the analog inputs and outputs will occur concurrently with
testing of the ADC and DAC. For testing the ADC we will ensure that we
can convert a signal from a 1/8" speaker jack into a digitized, packetized
signal that can be sent across the Zigbee chips. For testing the DAC we
will ensure that we can take a digital signal and output it to an 1/8"
speaker jack to be received and played by a set of powered speakers.

Once we have ensured proper operation of all individual components, we
will test sending the signals we recover from our ADC over the Zigbee
transmission line. If we can successfully receive these signals from the
broadcaster and subsequently convert the signal to analog for output, we
will have successfully tested the individual components of our project.

After all of the individual components have been tested, we will proceed to test the system as a whole. We will ensure that audio playback is smooth and synchronized with other units. We will also test audio quality and will improve or worsen it as necessary. Further, we will revisit the battery pack after the system is complete and ensure that our battery life is sufficient. We will test the systems in a variety of environments to determine susceptibility to noise or interference. During the environment testing we will test the range of the units and determine susceptibility to interference due to terrain.

Part of the design document

MANAGEMENT PLAN

Wireless radios are not cheap. So, in case the radios we pick don't work out, we'll start by creating only two repeaters as proof-of-concept. Once we get the repeaters communicating successfully with each other, we can add a third repeater to get an actual mesh network working, and then more repeaters if we feel like wasting money. This approach has the benefit of possibly saving us 20's of dollars if it turns out that the particular chip, or even the protocol itself, does not suit our purposes.

PROBLEMS THAT COULD ARSE ARISE

· The 8051 could be the wrong choice. We could find ourselves with too little memory to buffer correctly, or not enough processor speed to do stuff. The best thing we could do to prevent this was to not buy the cheapest 8051 out there. By buying 8051s that are more expensive than we might need, we at least know we have a pretty good chance of avoiding processor limitations.

· The XBee could be the wrong choice. It's conceivable that the XBee radio could be incapable of what we want, even though all the research we’ve done indicates that it is capable of implementing ZigBee mesh. Although unlikely, if this happens, we would simply have to absorb the cost of the two XBees we purchased, which is why we only obtained two initially. We would have to make the decision to change very early so we would have time to order and receive new radios.

· ZigBee could be the wrong choice. This is even less likely and even more disastrous, requiring us to research some other protocol. Our mitigation plan is to kill ourselves.

· We could screw up soldering something. This is pretty low-risk now that we have the breakout boards, because we wouldn't be destroying $20 radios. Still, we'll probably find an elite solderer to do this part for us.

· Static discharge lol

· We could never figure out those damn ADCs/DACs. We used an Analog Devices ADC last year and it was a miserable failure for some reason. Hopefully we can get it working; otherwise we'll buy a different one, possibly from a different manufacturer.

Currently, the cost breakdown is as follows:

· ZigBee radio: $21. This is the XBee Series 2 chip from MaxStream. It comes with a small whip antenna and is pretty awesome.

· XBee breakout boards: $8. These were an expensive luxury for prototyping. They allow us to adapt the XBee chips to our breadboards without soldering the expensive radios to anything.

· 8051 microprocessor: $8. 8051s can be as cheap as $1 or $2, but we sprung for a more expensive model with (primarily) more memory. We did this so we would not need to worry so much about things such as buffer capacity, and it had the additional benefit of getting us a 60MHz processor, as opposed to 12MHz, in case we need all those megahurtz. It's quite likely we could replace this with a cheaper processor once we optimize things.

· Analog-to-digital converter:

· Digital-to-analog converter:

· Breadboard: $12. For now, we're doing everything on breadboards. They are not cheap. They are also very bulky, so they would obviously not be used for the final devices.

· Switch:

· Line-in, line-out: Line-in will be used by (only) the broadcaster to feed music into the mesh network. Line-out will be used by the repeaters to send the received music out to a speaker, recorder, headphones, etc. It's possible to replace line-out with an actual speaker, but this removes a lot of flexibility from the system and also consumes more power.

· MP3 encoder/decoder: It's possible that ZigBee's bandwidth won't allow us to successfully stream audio of sufficient quality. In that case, we would need some sort of compression (MP3 is just used as an example here). A hardware encoder/decoder would not be cheap.

Our project's budget will be something along the lines of $50 per device. Currently, this seems possible; but if we need MP3 encoders/decoders, things could become very tight.

Conceptually, if these devices were commercially produced, it would not be economically viable to have them cost more than $40 (or $50 if you stretch your imagination). This is because although alternative approaches, such as a line-in FM transmitter, do not solve the problem in as robust a manner, they are usually relatively inexpensive.

DEVELOPMENT TIMELINE

· Get two XBees communicating data to each other. This would definitely not be audio yet; it would be something simple like text.

· Figure out audio. This is a large topic and I'm going to leave this very vague right now because I'm a jerk

· Buy a third XBee and get a mesh going.

TEAM POLICIES

· Documentation. We will document things in two ways. First, everything we discuss will be transcribed onto our blog. If it is trivial information that doesn't really need to be put there, it will be sent in an email to all project members with [PROJECT] in the title so it can easily be found. Both methods automatically timestamp all communications.

· Meetings. Well, y'know, we all live pretty close to each other. We meet basically every day. As for meeting with our mentor, we will attempt to do this once per week.

My work on the design document so far

Engineering Tools

What engineering tools have you used and do you expect to use in order to design and implement your project? Describe both software tools (compilers, debuggers, etc.) and hardware tools (logic analyzers, multimeters, etc.).

We will use text editing software such as Textpad or Notepad++ to write our code. To compile, we will use the Keil C cross-compiler for the 8051 microcontroller. For testing, we have debugging software (say what this is) which works with a hardware 8051 emulator (say what this is) to help us develop our software. The lab we are working in has Dell PCs, variable power supplies, and digital multimeters. The lab does not have any oscilloscopes or logic analyzers.

Standards

What standards (commercial, industry, international, etc.) did you decide to use and why? What other standards did you consider and discard and why? In what ways will the use of standards influence your project.

We will use the Zigbee wireless communications standard, because it fits our project's needs fairly well. Zigbee is designed for use with embedded systems, and it is meant for creating mesh networks. One downside of Zigbee is that it provides relatively low bandwidth. In our research, we considered using the 802.11 wireless standards, but we decided not to use them because they are not meant for mesh networking. The use of an existing standard will save us a lot of time and work, because we don't need to develop our own wireless mesh networking protocol. Because of the existence of Zigbee devices, all we have to do is buy some Zigbee radio chips and figure out how to interface with them.

System Architecture:

This section should present the high level structural design of the system. This section should describe how you arrived at the structure and what tradeoffs you explored.

System Architecture contents should include:
System Architecture Diagram
Functional Analysis and Requirements
Functional Description of Each Component
Subsystem/Component Alternative Generation and Trade-offs (for several of the most important design features)
Systems Engineering analyses pertaining to issues such as power/weight/error budgets, etc.
Experimental Analysis – Did you perform experiments to evaluate feasibility?

The main components of our project are a battery pack, an 8051 microcontroller, an XBee Zigbee radio chip, an analog-to-digital converter, and a digital-to-analog converter. Each unit will have an analog input, an analog output, and a power switch.

We decided to use the 8051 as our microcontroller because two of our group members have prior experience working with 8051s. We felt the microcontroller would be more than adequate for our needs. The model we will use has a fair amount of memory, is reasonably powerful, and does not cost very much. It is available in dual-inline-package, which makes it possible for us to prototype our project with breadboards. We wanted to get an 8051 that would have onboard ADCs and DACs, and possibly even an MP3 encoder/decoder, but such an 8051 is only available in a surface mount package that would be impossible to use for prototyping. It would have been useful for our 8051s to be in-system-programmable, but such chips are more expensive.

We chose the XBee Series 2 radio because it is a reasonably priced radio chip that does what we need. It is capable of forming mesh networks if it is set up correctly, using the Zigbee wireless protocol. The XBee has pretty good documentation, and the company that sells it has good support available. The XBee does not use much power, so it should be possible to keep it running for several hours. We considered some cheaper Zigbee chips, but they had far less features and would have been much harder to use. The XBee has a simple serial interface and is programmable, which means that using it should be relatively easy.

We will use batteries to power our project because it is meant to be a small, mobile unit, and so it would not be possible to run it off a permanent power source.

We will start by testing just two XBees to see if they work the way we want them to. If they do work, we will order more. To make sure the Zigbee protocol really does what we need, we researched how it actually works.