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.