Demo day, and our final enclosures

The transmitter, connected to my pink iPod.














Our awesome on/off switch.














An overhead shot of the transmitter. In the bottom left you can see the XBee radio chip. On the middle right, partially obscured by tape, you can see an Atmel AVR Butterfly. On the bottom is the headphone jack.














One of our receiver units. It has the same I/O as the transmitter - a power switch and a headphone jack.














The inside of a receiver. You can see the blue XBee radio chip, a Butterfly, and in the top left corner of the breadboard, a DAC chip.














Our "mobile" receiver. Inside the backpack is a receiver identical to the one in the above photos. The only addition is some cheap powered speakers.














A receiver, hidden inside the backpack.
















Next, some pictures from the Senior Project Expo, taken by our friend Manish. You can see his group's project at http://abstc.blogspot.com/

Kevin (in the red shirt) explains our project to someone.













Toviah (on the left) stares wistfully at Kevin as I (in the middle) contemplate life.













Toviah explains our project as I look on.













I explain our project to onlookers.

Remaining tasks

1. Construct a second receiver to demonstrate point-to-multipoint network somehow. We need more wire jumper things and we can't find the damn things
2. Make fancy enclosures for our units
3. Try to fix the popping noise
4. PowerPoint presentation
5. Minor code improvements. Mostly power consumption-related, such as disabling the extra ADC pins and the Butterflys' LCDs

Current state

The changes we made took quite some time to figure out, even though they're actually very simple things. But regardless, the result is a working project.

Transmitter



The iPod connects to a headphone jack, which connects to the ADC pin of the Butterfly. Then bits go flying out of the XBee! The MAX232 level converter is not really visible (it's obscured by the white cable).

Receiver



That hideous jumble of wires is a "bus" from the Butterfly's PORTD to the DAC. The DAC output voltage is connected to the headphone jack, which connects to our speakers. You can't see the battery unit in this picture, but it's the same as the transmitter's: 3 AA batteries. Surprisingly, the receiver can run everything off of 4.5V, including the DAC (5V nominal), speakers (7.5V nominal), Butterfly (3V, we only use two of the batteries for it), and the MAX232. Even then, it only takes something like 100mA to operate. The transmitter is as good or better. We've run the units for hours and they still have not exhausted their first set of batteries.

Audio quality is what you would expect with 8 bit samples at ~8,800 Hz. But it actually sounds pretty decent, if I do say so myself. We even have a lowpass filter set up on the input to the ADC pin on the transmitter. We tell ourselves we can hear a difference.

Range seems to be around 30 feet.

The cool thing about this project is that it's digital information being transmitted. This means that we can do all sorts of stuff other than streaming audio.

Thanks to Scott for the pictures. I should've done a better job of choosing pictures from the set for this post.

An update!

Well, a lot has happened since our last update, so I'll try to split it up.

ADC
Originally, we were using some ADC code we found on AVR Freaks. This code did single conversions, which is fine for some applications but obviously not for streaming audio. So instead we put the ADC in interrupt-driven mode and used the "ADC conversion complete" interrupt as its trigger. This is known as free running mode, and it improves the ADC's speed from 25 cycles/conversion to 13 cycles/conversion. Previously, we were using a timer to read the contents of the ADC at regular intervals (8,000 Hz). That was stupid. It resulted in lots of duplicate ADC readings because we would read the ADC output register several times between updates.

We chose a prescaler for the ADC clock that was around 8,000-9,000 Hz. That turned out to be Fcpu/64. When trying to decide on a prescaler, we mistakenly thought the frequency we were registering on our multimeter was the frequency of the ADC, and we were confused as to why it was half what we were expecting. Then we realized that it was because we were checking the frequency by watching a pin toggle each time the interrupt was triggered. It's an obvious mistake and not really worth explaining. Incidentally, it turns out the ADC tops out at around 11,400 conversions/sec when doing 8 bit conversions (slower when doing 10 bit).

DAC
First off, we got the DAC. That's pretty important. Other than that, it's a very straightforward component: send it parallel digital input (12 bits max) and it spits out analog. It can work transparently, which makes things very easy.

The receiver unit receives digital info from its XBee and places it in a circular buffer, which is currently 512 bytes for no particular reason. It also has a timer that plays samples at roughly 8,800 Hz, then deletes that sample after playing it.

With a little tweaking, we got the timer on the receiver to fire at approximately 8,800 Hz, which was about the rate the transmitter was sending at. Unfortunately, any slight difference between the transmitter and receiver rates results in a perpetual popping noise. This is because the two units will inevitably go out of sync and the receiver's buffer zeroes out.

One solution would be to make the DAC not zero out the buffer. Then the popping noise would not be as noticeable, although it isn't really all that noticeable to begin with. Otherwise, we would just have to tweak the clock seed until the receiver's speed is close enough to the transmitter's speed that the popping is not very frequent. I don't think it can be eliminated entirely.

Breakout Board Order

8 x 2mm 10pin XBee Socket (SKU#: PRT-08272) = $10.00
4 x Breakout Board for XBee Module (SKU#: BOB-08276) = $11.80

Sub-Total: $21.80
Shipping & Handling: $3.30
Grand Total: $25.10

Total project cost so far is $426.28.

XBee Order

3x XBee Series 1 at $19.00 each = $57.00
4x thermistor at $0.13 each = $0.52
4x thermistor at $0.15 each = $0.60
4x thermistor at $0.13 each = $0.52
Shipping = $6.69
Total = $65.33

Total project cost so far is $401.18.

Even more progress

Thursday Update

Since we got the USART working last time, our goal today was to start using the XBees with the Butterflies. First we set up the XBees with the development boards and had them broadcast to each other; then we set up the Butterflies with MAX232s and had them receive a broadcast from one of the XBees connected to a dev board. Writing this makes it sound quick, but it most certainly was not. But we now have a true point-to-multipoint network setup.

And we did some other stuff but it's late and I want to sleep.

More progress

Tuesday Update

We got the Butterfly's USART working. We are now able to send serial data to and from the Butterfly at 115k baud (the highest rate the XBees will be able to use) with 0% error. This allows us to easily test the ADC by having it spit readings to HyperTerminal. It appears the ADC is fully functional.

We also worked on the pre-amplifier for the ADC. The voltage levels we get out of line level MP3 players and audio jacks seems to range between 0-0.3V. The ADC can read values between 0-3V. So in order to utilize the ADC's full precision, we will need to amplify the input by a gain of about 10, we think.

Progress!

01-31-08: We've mostly figured out the A2D. ADMUX is used to pick the input channel for the mux (we're not sure what physical pins the channels correspond to yet). ADC stores the converted data. We also got the LCD to display text.

Next time: use BitScope to find which pin we're reading.

More ADC code, discussion

AVR Freaks thread

ADC sample code

Here is the site where some ADC code can be found. It's inside the 0.7.2 zip file as ADC.c.

I put the AVR Studio installer (aStudio4b528.exe) on the Memorex flash drive. It's 73Mb and you have to register on their site to download it, so you can use that if you want to save a step.

Development Kit Order

1x XBee 802.15.4 Starter Kit at $99.00 each = $99.00
Sales tax = $7.67
Shipping = $8.38
Total = $115.05

Total project cost so far is $335.85.

Breadboard Order

2x 6.5"x3.125" 1360pnt Breadboard at $13.65 each = 27.30
Sales tax = $1.98
Shipping = $7.42
Total = $36.70

Total project cost so far is $220.80.

Butterfly Order

3x AVR Butterfly at $21.28 each = $63.84
Sales tax = $4.95
Shipping = $2.83
Total = $71.62

Total project cost so far is $184.10.

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.

Power estimates

XBee Series 2
TX, RX Current: 40 mA (@3.3V)
Transmit power: 2 mW (+3 dBm)

8 bit ADC, 200kSPS (leftover component from last year)
- Normal Operation
10.5 mW, VDD = 3 V
- Automatic Power-Down
57.75 µW @ 1 kSPS, VDD = 3 V
Max Pwr Diss
17.5 mW

DAC
not selected yet

8051
We're having trouble finding power numbers for our 8051, but we'll keep looking

SST MELODY. We're not going to use this.
load capacitance x Vdd^2 x output switching frequency