Software Design top

Our software consists of firmware for the microcontroller and a PC program that streams audio to the microcontroller. The PC program is currently compatible with 44.1 kHz, single channel wave files, or 8 bit, 22.05 kHz, dual channel wave files. Though the audio data is transmitted to the microcontroller as raw PCM so any music file that can be downsampled to meet either of the above criteria could be played with only minor modifications to the PC program.

Microcontroller Software

Microcontroller software was written and compiled in AVR Studio 5.1. The microcontroller code was derived from a number of low level libraries available as Atmel application notes. Specifically notes AVR1304, AVR1516, AVR1518, AVR1520, and AVR1522 were used. "-O3" optimization was also used.

In order to sustain a high rate of data throughput in addition to the exact timing requirements of audio, we used many hardware features of the xmega series. In all, we utilize the USART, both channels of the DAC, three channels of the DMA, two channels of the Event System, and two Timers.

The DMA system was a major pain. We had to do a number of undocumented and unorthodex steps to setup the DMAs to correctly transmit at a relatively continuous rate.

Overview

The system works as follows. Immediately after power on, the clock is switched from the default 2 MHz oscillator to the 32 MHz oscillator. Then the DFLL and the 32kHz internal oscillator are used to trim the 32 MHz oscillator to 33868800 Hz, which is evenly divisible by 1024 Hz (the resolution of the DFLL) and 44.1 kHz, the rate at which music is played.

After clock trimming. The DFLL is disabled and all clocks excepted the 32 MHz clock (now trimmed to 33868800 Hz) are disabled. Input and output ports are then configured and the USART baudrate is set to 9600 baud, the default baudrate of the Wifly. The DAC, timers, Event System, and DMA are initialized along with appropriate buffers. Then Wifly initialization commands are sent which configure to Wifly to join or create a Wi-Fi network and set up the the IP address and port numbers of the remote client that will be streaming music.

After this setup, the baud rate is configured to 921,600 baud and the receiver begins waiting for audio packets.

Initialization and Configuration

The first peripheral to be initialized is the DAC. We initialize both channels of the DAC so that we can play two channel (stereo) audio. In in the initialization of the DAC we enable the optional audio amplifier and enable two timer interrupts. We enable the timer interrupts here because we use one of the timers (Timer C0) to trigger a DMA conversion, and therefore it runs at 44.1kHz (period of 768). The other timer (Timer D0) is used to keep track of milliseconds. We need to keep track of real time for reasons discussed later when discussing audio streaming. After enabling the timers, we setup the DMA for dual channel operation so that the DAC will convert the samples from both channels and play them at the same time. We also set the event control register so that both DAC can be triggered individually.

After setting up the DAC, we initialize the onboard USART. To do this we first set the appropriate pins to output/input in order to setup the TX/RX lines. We then initialize the USART buffers and enable the USART receive interrupt (transmit interrupt is enabled later). Note that we initially receive and transmit data over the USART using interrupts. This is only done in the initial setup of the Wifly. After the Wifly setup is complete we continue to transmit data using USART interrupts but we use the DMA to handle incoming data. The reason for this is that using the DMA to setup the Wifly proved to be very difficult and hard to debug. We also set the microcontroller baud rate to 9600 (the default Wifly baud rate). After USART initialization we enable global interrupts so that we can start receiving and sending data.

Once we can receive and send data we start initializing the Wifly. The Wifly module has its own independent 32-bit processor and onboard TCP/IP stack. This means it is able to do most of the networking calculations on it own as long as it's configured correctly. To setup the Wifly, string commands must be sent to its UART receive port. This is simple enough but there are many annoying subtleties that can only be discovered through experimentation. These subtleties can be seen later in the Tips/Tricks section for the Wifly. To initialize the Wifly we put the Wifly into command mode and then do a factory reset. This makes sure all previously saved configurations are no longer present and is important when switching between networks. After resetting, we enable the ad hoc network if we are not connecting to another network. We then setup the Wifly to send and receive UDP packets and tell it what port and IP address to send to and listen on. Next we set the communication time which determines how long data the Wifly receives from the microcontroller will stay in the Wifly's buffer before it is sent out in a UDP packet. The Wifly configuration is then saved and the Wifly is reset so the commands take effect. After the reset, if we are going to join RedRover we do so. The reason we wait to join RedRover is so that the IP address the Wifly gets from the DHCP will be printed out on Putty. Next we send the command to "instantly" set the baud rate of the Wifly to 921,600 baud. The reason we use the "instant" command is so that the baud rate will be changed without another reset and when the Wifly is power cycled it will start back at 9600 baud. After all this, the Wifly is initialized and we disable global interrupts.

The last thing we do before we start streaming is clear the USART buffer. We do this by simply writing all of the data to one element of a trash buffer. This ensures that there is no junk data put into the audio buffer when we begin streaming.

Music Streaming

The system to deliver audio to the DAC is somewhat complicated. So to explain the system, we will work outward to inward, starting from the analog output from the DACs and ending with when it is received by the USART. To output sound to both speakers, we use both channels (channels 0 and 1) of the DAC unit, one for left and one for right. In order to update analog values reliably at 44.1 kHz we used the DAC trigger feature. The DAC can be configured to update its output based on a signal from the Event System. We therefore set Channels 0 and 1 of the DAC to trigger from a signal on the Event System channels 0 and 1, respectively. Channels 0 and 1 of the Event System are triggered when an overflow of Timer C0 occurs, because the system clock is a multiple of 44.1 kHz, Timer C0 can be set to overflow at a rate of exactly 44.1 kHz. So the DAC can be updated at an exact rate of 44.1 kHz with no CPU interaction necessary.

To load values into the DAC data register without CPU intervention, another xmega feature is used, namely the DMA. Two channels of the DMA are setup to transmit blocks of data from a buffer to the DAC data register. The DMA transfers trigger on the DAC data register empty condition, which occurs immediately after the DAC has read in the values in its data register and used them to output a new analog voltage on its DAC output pin. The DMA transfers are configured as single shot. Meaning that they will only send one burst of data (in this case, 1 byte) for every trigger condition received.

After the DMA has completed an entire block transfer (nominally 128 bytes, equivalent to 128 audio samples). It must be periodically reset to load in new data to the DAC. This is accomplished in the Timer C0 overflow interrupt. Because the Timer C0 overflow triggers the DAC update (and consequently the DAC data register empty condition and a subsequent DMA transfer). The Timer C0 overflow interrupt is the perfect place to detect the final DMA transfer and setup the DMA channels for a new block transfer. To do this, a static variable keeps track of the number of overflows that have occurred since the current DMA transfer began. When this number gets to the final transfer, the overflow ISR resets this variable and updates the DMA channels to send a new block.

Audio data for the right and left channels are each kept in their own circular buffer. These audio buffers are large, 4 KB each. The DMA channels that send data to the DAC pull data from these buffers. Data is placed in these audio buffers by the CPU. After initialization, the microcontroller enters a function, Begin_Stream(), in which it stays forever. In this function, the CPU takes data from one of three temporary buffers and places the data into the audio buffers. The data gets into these temporary buffers through yet another channel of the DMA.

Channel 1 of the DMA is initialized at the beginning of the Begin_Stream() function to receive the incoming data from the USART. When the DMA is initialized, the first thing done is disabling the USART receive interrupt used earlier to receive data while configuring the Wifly. The DMA is setup to trigger on a USART receive complete and to have a block size of 128 bytes. This, by no coincidence, is also a multiple of the size of the packets we send from the computer. Additionally, we use three temporary buffers so that after a block transfer is complete, the CPU can start moving data from the temporary buffer to the audio buffer while the DMA fills a different temporary buffer with data from the USART.

PC Audio Streaming Program

The PC audio streaming program works to stream audio to the microcontroller over UDP. It searches for wav files in the given directory and automatically streams them in order to the microcontroller, the user can also pause, go to the next and previous song using the computer's play, next and previous keys.

The PC audio streaming program was written in Notepad++ and compiled using MinGW on Windows 7 (32 and 64 bit versions). It uses libsndfile (licensed under the LGPL), code derived from Glenn Fiedler's website (available on his website with no apparent license, thanks Glenn), libwsock32, and native windows calls.

Functionality

The streamer program uses libsndfile to read wav files. It currently supports either mono wav files at 44.1 kHz or 8 bit stereo wav files encoded at 22.05 kHz. The streamer can be run from the command line, where the first parameter passed is the folder it should look in to find wav files. The program builds a list of all the wav files in the prescribed directory, then begins streaming the wav files to the microcontroller. While the script is running, the user has the ability to skip songs, go to a previous song and pause the music by using keyboard shortcuts.

The IP address of the microcontroller must be compiled into the program beforehand.

External Libraries

• libsndfile (licensed under the LGPL)
• libwsock32 wrapper was copied with minor modifications from Glenn Fiedler (available on his website with no apparent license, thanks Glenn)

The MAD Dog Streamer terminal the user interacts with while streaming music.

Streaming Algorithm

The algorithm we used to stream audio proved to be the most robust and accurate algorithm we could come up with. Though it has a relatively simple design, it proved to work quite well. First, we calculate the rate at which packets should be sent by determining how long it should take the microcontroller to play all the samples in each packet (taking into account channels and number of bit samples). We then send packets from the computer at the exact rate we expect them to be played. On the microcontroller side, we wait until we receive a certain threshold of samples in the audio buffers before we start playing audio. This allows use to have some leeway with poorly timed packets. Additionally, we implement a feedback system to tell the computer when we have too much data or not enough. After audio gets enabled, whenever we cross a specific lower or upper bound threshold for data in the audio buffer we send the computer a one byte data packet. In order to not overwhelm the Wifly (which is very easy to do) we limit the sending rate of these feedback packets by keeping track of a real time clock. Each of these packets contains either the letter "S" for slow or "F" for fast. When the computer receives a packet from the Wifly, it examines the contents and reacts accordingly. If the packet contains an "F" then computer knows it needs to speed up its packet send rate. Therefore, two things happen. First, the current interval (time before it sends the next packet) is increased by a factor greater than 1. This allows the data in the audio buffers to go down a bit before the next packet is received. Additionally, the normal transmission interval is also changed by a very small factor. This allows for fine tuning of the transmission interval while the song is playing. A similar thing is done when an "S" is received except the interval is decreased so packets are sent faster.

We also added the functionality that when the Wifly does not receive data for a certain amount of time (~4 seconds) it disables audio. This saves power by not requiring the Wifly to send packets requesting faster data and allows for the buffer to refill to the threshold when the audio begins again.

Hardware Design top

The major sections of the hardware design are the power regulator, xmega and Wifly, and audio filters. Somewhat incredibly, we had no major problems with the hardware design.

Voltage Regulator

The xmega and Wifly module both operate at 3.3V. The Voltage regulator is a 3.3V regulator with two smoothing capacitors. The capacitor values were chosen based on the specified values in the datasheet for the voltage regulator (see References).

Microcontroller

The microcontoller section includes the ATxmega256A3U and the Wifly RN-XV-W. These two are connected through a UART interface. In addition the two have voltage stabilizing capacitors located near their Vdd and ground pins as specified in their data sheets (see Appendix).

An image of the ATxmega256A3U on the breakout board.

We chose to use the ATxmega256A3U microcontroller for this project because it operated at 3.3V (same as Wifly), it had an AES Crypto module (which we would have used had we been able to implement Apple Airplay), it had two DAC modules that we needed for playing 2-channel audio, it had four channels of DMA which was needed for data transfer without CPU usage and it had a 32MHz internal oscillator which was needed to perform all the necessary calculations quickly.

The xmega is programmed via the Atmel proprietary PDI interface. Schematics for this were derived from the Atmel application note for the schematic design of the atxmega series (see References). The xmega microcontroller came as a surface mount chip, which we soldered onto a breakout board in order to access the pins through a bread board.

The Wifly module also required an additional breakout board because the pins on the module itself were too close together to fit into a breakboard. Additionally, the Wifly module has a pull-up resistor on its reset pin to keep the pin high. The reset pin is active low so the pull-up resistor is wired to 3.3V to keep the pin high.

Audio Filters

The audio section filters the raw analog output from the xmega's DACs. The audio section includes a decoupling-high pass filter with a very low time constant and a low-pass filter with a time constant just above 22 kHz. These filters work to remove unwanted noise from the audio signal.

To simplify design and reduce costs, we opted to not include any kind of pre-amp, instead relying on the speakers to perform any audio amplification. While this may limit the utility of the microcontroller to drive certain loads, we did not experience any adverse effects of this design.

Results top

Our final music streamer was able to stream 8-bit mono music quite well at 44.1kHz and 8-bit stereo at 22.05kHz. Though we would have liked to have been able to stream 16-bit samples, the rate at which we could get data from the Wifly wouldn't allow it. When streaming 8-bit mono at 44.1kHz however, the audio sounded quite good and the lack of bit precision was not even noticeably. Additionally, since we streamed mono audio by outputting the same data on both speakers, the lack of stereo was really not too noticeable either. The only really noticeable errors we experienced were occasional skips in the music. These skips, we determined, are due to a variety of things but are ultimately caused by not having enough data in the audio buffers or receiving too much data for some amount of time. The main reasons for these problem are because the Wifly gets overwhelmed and misses packets (because it is sending or receiving too many packets), there is too much congestion in the network (if we are on RedRover), our computers have some lag while running the streaming program (happens when other programs take a lot of the CPU) or other entropy.

Sometimes when a packet is dropped due to network congestion or other non idealities the receiver skips and the music seems to fast forward. This is due to the streamer missing samples and thus playing "future" samples, creating a sort of fast forward effect.

Other errors that we sometimes experience while streaming music are Wifly failures. The two main failures we get are "Misaligned address" and "High Speed Optimization Error." Both of these errors cause the Wifly to crash and stop sending packets. These errors happen somewhat rarely and are due to failures in the Wifly module and not in our actual code. As we stated earlier, we are pushing to Wifly harder than it is meant to be pushed so errors such as these are expected.

The ad hoc network that we ran our streamer on was configured to run on 802.11 channel 4. The reason we chose channel 4 is because in the ECE lab there were no other networks using channel 4 and therefore we were causing the least interference possible to others. When we streamed over RedRover we did add to congestion and interference but not much more than a person streaming video or music to their computer.

Our final audio streamer software for the PC was made very user friendly. We were able to allow the user to change song, pause and play the music using the 'Play/Pause,' 'Skip' and 'Go Back' media center buttons present on most Windows computers. The script also displays a list of songs available in the specified folder (in wav format) to the user so the user can easily navigate to the song they want to hear.

Conclusions top

Analysis

Originally we had wanted to create a system that integrated with Apple Airplay. This proved impossible with the hardware we were using, in particular, the Wifly module only supports connections with a single IP address and port at a time, which meant that we could not support zeroconf (mDNS/DNS-SD) or RTP, RTSP, and RTCP which require simultaneous connections on different ports and addresses. Despite this, we were still able to write our own program on PC that streamed music to the microcontroller in a similar fashion to Airplay, even if it didn't integrate with the Airplay ecosystem.

We also were unable to play 16 bit stereo at 44.1 kHz. Realizing that the link in between the Wifly and the microcontroller controller (as well as the Wifly module itself) could not sustain baud rates high enough. We did get 8 bit single channel audio playing at 44.1 kHz and 8 bit dual channel audio playing at 22.05 kHz. We found the sound quality at these rates to be very close to the quality of the audio when played at higher bitrates.

The xmega proved integral to our design, moving many of the data intensive portions of our program to hardware, done again we would definitely choose this microcontroller. The Wifly, however, proved to be difficult to interface with at the high baudrates we required. It was likely designed for less data intensive situations. Next time we might choose a different Wi-Fi adaptor, perhaps trying to create a USB host controller that could interface with one of the numerous existing USB Wi-Fi dongles. A design like this would perhaps use the MAX3421E USB peripheral/host controller integrated circuit to implement many of the low level functions in hardware.

We also lost significant time debugging at high baudrates and configuring the DMA controller on the xmega microcontroller. Eventually we configured a serial interface onto USART connection between the microcontroller and the Wifly which helped a lot when debugging, but if we had done that earlier, we would have saved ourselves a lot of time.

Room for Improvement

The PC streaming program can be improved in a number of ways:

• Add functionality for reading audio files with different codecs, for example by incorporating ffmpeg into the streamer program
• Capture audio output to the sound card and transmit that to the audio receiver. This is not terribly difficult on Linux (see PulseAudio) but is more challenging on Windows.
• The data sent between the PC and the audio receiver is currently uncompressed PCM. Using a compression scheme would allow data transmission at higher bit rates.

The microcontroller can be improved by:

• Adding a service discovery protocol to enable zero configuration between the PC and the receiver which would remove the need to configure the IP addresses of each device by hand
• Supporting a different Wi-Fi NIC to allow higher data rates or enable multiple simultaneous IP connections
• Adding external RAM would allow for larger buffers, making playback smoother and enable the use of either TCP or an application layer protocol that guaranteed packet order and delivery, enhancing sound quality
• Implementing an audio codec decoder so that less data will need to be sent for each sample

Standards

Our design is compliant to 802.11 standards, which are about the only standards that apply to it.

Intellectual Property Considerations

We re-used code from a bunch of places. We used Atmel notes AVR1304, AVR1516, AVR1518, AVR1520, and AVR1522. We used network wrappers from Glenn Fiedler which can be found here. We used a small snippet to look at directories from Danny Kalev which can be found here.

We also looked at some examples from the following websites but didn't specifically re-use any code.

• Mochima
• C++

To test and demonstrate the capability of the streamer and microcontroller, we played copyrighted audio. However, due to "Fair Use" using personally owned copyrighted material for this purpose should be ok (the Fair Use description in itself is rather vague but for all intents and purposes the use of music for reference even in a video is acceptable).

The code we used was under license and thus was not in the public domain. We did not reverse engineer any designs. We did not have to sign nondisclosure to get a sample part. We don't feel are design is sufficiently new and novel to be patentable.

There may be publishing opportunities for our project specifically because there are likely people who are looking to make their own Wi-Fi enabled audio receivers or expand upon our project.

Ethical Considerations

While working on this project we strove to do our best to follow the IEEE Code of Ethics. During our time working in lab, we were respectful to all other students and faculty. We tried to be supportive of other groups and assist anyone who asked for help. While working in the lab we consistently kept an open dialog with other groups and periodically checked in to see how things were going for them. We also gladly explained our project to people and informed them of the possible applications of such a project.

In addition, we utilized the knowledge of others, especially Bruce and the TAs, whenever we were having trouble. Specifically, we talked a lot with a TA who is doing a project very similar to ours as his MEng project. We were able to compare methods with him and bounce off ideas. Throughout the process of designing this streamer, we took every opportunity to improve our technical knowledge and understanding. Everything we implemented in our project we tried to fully understand before adding it. We sought assistance from those more experienced whenever there was a topic or concept we couldn't comprehend. Additionally, we used some code sample from online sources and cited them duly in this write up.

While in lab we did our best to be safe and courteous at all times. We followed all safety procedures while soldering and using other lab equipment. We also were conscious of static discharge and consistently grounded ourselves before touching any of the microcontrollers. Since our project required audio output that could be distracting to some peers, we used headphones to listen to the output whenever possible.

Legal Considerations

The Wifly module we use is Wi-Fi certified. We can't think of any other legal considerations.

Appendices top

Appendix A - Code

The source code for our project can be downloaded here.

Appendix B - Schematics

A schematic describing the hardware used in this lab can be seen below.

Schematic of hardware used in project

Appendix C - Bill Of Materials

The chart below shows the overall cost of our project and what exactly we used.

PART	PART NUMBER	VENDER	COST	QUANTITY	TOTAL COST
--	--	--	--	--	$69.49
3.5mm Audio Jack	CP1-3523N-ND	Digikey	$0.84	1	$0.84
WiFly RN-XV-W	WRL-10822	Sparkfun	$34.95	1	$34.95
xbee Breakout Board	BOB-08276	Sparkfun	$2.95	1	$2.95
3.3V DC Regulator	497-1491-5-ND	Digikey	$0.68	1	$0.68
TQFP 64 Breakout	MicrocontrollerShop	DR-SMD2DIP-QFP64	$4.50	1	$4.50
ATxmega256A3U	ATXMEGA256A3U-AU-ND	Digikey	$9.75	1	$9.75
Capacitors and Resistors	N/A	ECE Lab	Free	N/A	Free
Power Barreljack	CP-002A-ND	ECE Lan	$0.92	1	$0.92
AC to DC Power Converter	N/A	ECE Lab	$5.00	1	$5.00
Solder Board	N/A	ECE Lab	$2.50	1	$2.50
Sip Pins	N/A	ECE Lab	$0.05	148	$7.40
Speakers	N/A	Owned	Free	1	Free

Appendix D - Task Division

The chart below shows how the tasks were distributed for this project.

Mark	Both	Doug
Audio Streaming Algorithm	WiFly Initial Setup	Timer/Baud Rate Setup
Enabling Stereo output	Optimizing Audio Output	DMA and DAC Configuration
Solder Board Contruction	General Debugging	Hardware Desgin
Website	Documentation	C++ Streamer Design

Appendix E - Tips/Tricks for Wifly

The Wifly is a great little module, most but not all, of the below observation below occurs only when pushing it to its limits at super high baud rates. If you count yourself among the brave and which to push the Wifly to regions it was never intended to be in, best of luck to you and read on.

1. When debugging, always view the output from the Wifly on serial terminal. It is nearly impossible to debug a system without seeing the output of the Wifly. Sometimes the Wifly doesn't receive commands correctly, will respond in odd ways, or encounter an error and require a hard reset.
2. Always wait for a response (i.e. AOK, CMD, EXIT, etc.) from the Wifly. If you don't wait for a response commands will likely not be interpreted correctly. Adding a delay after sending a command will work sometimes but not always. Waiting for the appropriate response is the best bet.
3. If you are using the Wifly at high baud rates you must add a delay between each character you send (about 10 microseconds at 921,600 baud). Even with this though, expect commands to not get interpreted correctly sometimes (see step 1).
4. For every command (with some exceptions) to take effect you must save the configuration and reboot the module (with the reboot command).
5. If you are switching the network you are going to connect to, it is a good idea to do a factory reset of the system before switching networks.
6. Do a firmware upgrade as soon as you can send commands and connect to a network. This might save you some problems or at least save you from having Roving Networks support tell you to upgrade the firmware when you call with a problem.
7. If you need to send packets at a very high rate from the Wifly, setting the "comm time" to a low number is the most effective. As of firmware revision 2.32, the comm match and comm size settings work but not at high packet rates (>20 packets/sec). At least we couldn't get them to work.
8. Under serious loads, sending data to the Wifly will cause it to drop packets it is receiving over Wi-Fi. This will cause problems if you aren't using TCP or trying to get data at a fast rate (for example when streaming music).
9. Using the Wifly at 921,600 baud is pushes the Wifly to its limits. It works (usually) but you need to baby it a little bit. Don't expect it to be able to sending or receive anything close to 921,600 bits/second. It will straight up drop data.
10. The Wifly defaults to send out a broadcast message every so often. This can be useful for some applications, but if you know you will be constantly transmitting, it can also be a nuisance. This broadcast message can be easily turned off.
11. (For Cornellians:) If you want to connect to RedRover all you have to do is register the Wifly's mac address here and then you can join the redrover network.
12. If the Wifly behaves oddly for no apparent reason, power cycle the Wifly and do a factory reset using GPIO9. This is different from sending the factory reset command over the serial connection and will sometimes fix the problem.

References top

Data Sheets

• LD1117 Power Regulator
• PJ-002A Power Plug
• SJ1-352XN Audio Plug
• WiFly User Manual
• WiFly Datasheet
• Xmega Complete Data Sheet
• Xmega Schematic Checklist

Vendor Sites

• Digikey
• Sparkfun Electronics
• Roving Networks
• Atmel
• EZPrototypes
• MicrocontrollersShop

Software Design Sources

• ATMEL Sample Code
• Informant
• Mochima
• C++

Hardware Design Sources

This project did not have a strong emphasis on hardware and therefore we have no hardware sources other than the data sheets already listed.

Acknowledgements top

Mark and Doug would like to thank Bruce Land and all the ECE 4760 TAs that helped us so much on this project. We would also like to thank all the other 4760 lab groups who provided support and entertainment during the countless hours in lab. Lastly, we would like to give special recognition to Sam Odle and Laura Stamp for being so supportive and reassuring during the few times we were social and not in lab.

---

©2012 Cornell University