Eye Can Hear YouMichael Cooke, David Griffen, Whitney Keith,

Edward Romero

School of Electrical Engineering and Computer Science, University of Central Florida, Orlando,

Florida, 32816-2450

Abstract — An audio switching network composed of wireless headphones and television audio is implemented to enhance mobility and selection in a multiple audio application. Users can wirelessly “lock-in” audio from a television within their line of sight through a button press. Additional features include RSSI based triangulation that is able to track headphones within a region and graphically display the location on a tablet through an Android application. The graphical user interface (GUI) will display headphone registration, restaurant setup and an emergency headphone kill switch. The usage of four different wireless technology applications, 900MHz Radio Frequency (RF), 2.4GHz RF XBees, RF Bluetooth protocol and Infrared Pulse Width Modulation (PWM), produces a unique and challenging project.

Index Terms — Pulse width modulation, Infrared detectors, audio systems, radio frequency, headphones, wireless communication, graphical user interfaces.

I. INTRODUCTION

Developed and designed to enhance a mobile audio environment for restaurant customers, Eye Can Hear You (ECHY) allows users to lock in audio from one television within a network.. The project provides customers with a mobile audio experience as well as delivering quality sound. A main board was developed to control the subsystems of the project such as audio switching, audio streaming, and a communication bus to the application module. A wireless headphone to television identification system is designed to send a custom encrypted message using infrared LEDs from a headphone to a detector located on a television. The detector decodes the IR message and communicates the decrypted message to the master board. The master board also receives all television audio within the network and streams the audio to a specific headphone depending on the message received from the detectors.

Security of the headphones is enforced with an Android application on a tablet which is used to register and monitor the headsets. Location of the headphones will be

determined by RF triangulation. The location will be wirelessly transmitted to the tablet for the user to monitor. The application will also implement an enable/disable switch that allows the tablet user to initiate/terminate audio transmission to the headphones.

II. SYSTEM CONFIGURATION

The system is implemented in a sports bar like environment with multiple televisions for customer entertainment. At several sports bars one television dominates the audio of the room and customers are subjected to viewing other televisions without the corresponding audio. ECHY allows multiple users to wirelessly choose which television to listen to.

Fig. 1. Project system layout

The triangulation system as seen in Figure 1 shows four nodes, each located at a corner of the room. The master board will be wired straight into the modules from each television and television audio. The tablet is able to communicate to the master board and each headphone via Bluetooth and Xbees.

II. COMPONENTS

A. Microcontrollers

The three microcontrollers used in this project are the Stellaris, MSP430, and Atmega328.

The particular Stellaris chosen is the Texas Instruments LM3S8962. The Stellaris is used on the master board since it is able to handle vast amount of General Purpose Input Output pins (GPIO) for multiple system communication. All the subsystems together take up 25 GPIO pins from the master board which satisfies the original reason of choosing this processor. The subsystems controlled by the board are the sound switching, the audio enable/disable switch, and the transmission of the audio.

The MSP430g2231 is implemented on the headphone and the IR detector boards. The MSP430 was chosen due to its low power consumption, input interrupts, PWM output, capture and compare registers, and 8 GPIO pins.

The ATmega328 is used in the RF triangulation subsystem. The Atmega was chosen for its high flash memory capacity, multiple serial data ports capability, and high precision in arithmetic operations.

B. Wireless Technologies

The wireless technologies used in this project are 900MHz IEEE 802.11, 2.4GHZ IEEE 802.15.4, Bluetooth supporting SPP/Dun and HCI, and 940nm Infrared.

The audio for the headphones will be transmitted through the unlicensed 900MHz frequency spectrum. The master board will use the Linx Technologies (TXM-900-HP3-PPO) transmitter module, while the headphones will use the (RXM-900-HP3-PPO) receiver module. The compatible modules transfer audio via a frequency modulated (FM) signal at long distances exceeding 50 feet.

The 2.4GHz module used is the Xbee S1. This module is used in the Radio Signal Strength Indication (RSSI) based triangulation subsystem. The RSSI is measured from each of the Xbee modules (nodes) and converted into a distance constant unique to that measurement. The triangulation algorithm used for GPS is then used to figure the coordinates of each of the headphones in respect to the origin at one of the corners.

The Bluetooth is used to transmit the enable/desable commands to the master board. The RN-41 Bluetooth module mounted on the master board was chosen for its embedded Bluetooth stacks and the auto discovery. The tablet and module are Bluetooth compatible.

The IR is used in the audio switching and headphone identification. The IR PWM signal was chosen because the line of sight propagation of the LED and the PWM ability to send a unique identification at a reasonable distance.

III. SUBSYSTEMS

The project consists of four subsystems, headphone-to-television identification, audio switching and transceiving, RF triangulation, and a graphic use interface (GUI).

A. Headphone-to-Television Identification

This subsystem is responsible for identifying which headphone user is viewing a particular television within a network. The designed wireless headphones include an array of IR LEDs, used to transmit an 8 bit PWM unique

to each headphone when a button is pressed. A detector board located on each television contains an IR sensor to capture the IR PWM signal sent from each headphone. The captured signal is decoded and compared by the MSP430 to determine which headphone is viewing the television. The MSP430 communicates the specific headphone ID to the master board for sound switching.

B. Audio Switching and Transceiving

Once the particular headphone ID has been received by the master board, the Stellaris microcontroller unit (MCU) processes the ID for audio switching. Located on the master board are two multiplexers (MUX), one per headphone. Each multiplexer has audio from each television as inputs. The Stellaris uses the multiplexers to re-route the audio to the desired headphone.

C. Radio Frequency Triangulation

The headphone localization system consists of RSSI based triangulation. Each headphone is able to find its own location by using the four Xbee modules localized in each corner of the system. The idea is that the headphone uses the Atmega328 to talk to the Xbee module via serial communication. It tells the Xbee to call for every Xbee in range and the Xbee returns each Xbee’s unique ID, address, and RSSI measured to the headphone. The atmega328 takes this data five times, and calculates an average. This average is then compared with a data table containing RSSI to distance conversions from each Xbee. Three circle intersection geometry is then used to figure out the (x,y,z) coordinates of each headphone in reference to the origin being one of the corners.

D. Graphical User Interface

The graphical user interface allows staff to register and locate headphone users, create room dimensions and view headphone status. The GUI communicates with the master board and the headphone Xbees to enable or disable audio to the headphones and retrieve headphone location data respectively.

IV. HARDWARE

A. HeadphoneThe headphones were designed to ensure wireless audio

compatibility between the receiver and transmitter instead of purchasing and modifying wireless headphone hardware. The headphone hardware consist of two printed circuit boards (PCB) mounted one on top of the other. The first PCB controls audio receiving, audio buffering, volume, and the infrared PWM signal output. The second PCB calculates the position of the headset, and then

transmits its position to the tablet. The PCBs are mounted on the band of the headphone to ensure line of sight infrared transmission.

The television audio for the headphone is received on a 900MHz radio frequency using Linx Technologies RF module (RXM-900-HP3-PPO). The module can receive on 9 different RF channels within 900-922 MHz. To utilize the multitude of channels, a DIP switch was connected to the channel select lines. The headphone receiver and master board transmitter must be on the same channel as in Figure 2. A 50Ω quarter wave antenna with a RP-SMA connector compliant with the FCC’s Part 15 rule was chosen. The antenna is placed on a PCB ground plane to reduce noise. The module was ideal for this application since it handles an FM to AM signal conversion without external components, simplifying the output of the module to an audio out pin.

Fig. 2. Detector circuit to decode headphone infrared PWM.

After the audio is outputted from the RF module it is buffered to clean up the signal and lower the impedance into the speakers. The audio is first passed through a dual gang audio taper potentiometer, which is used to increase and decrease the volume. The audio is handed to an operational amplifier (Op-Amp) (TL082). The Op-Amp circuit is based off a buffer and a modified 2nd order band pass filter circuit as in Figure 3. To power the Op-Amp, a +4.5 and -4.5 voltage supply is necessary, therefore the 9V battery was split using a voltage divider. Lastly, the audio is sent to the 8 ohm speakers for the user to enjoy.

Fig. 3. Audio amplifying and buffer circuit.

For headphone-to-television identification a 2x3 array of IR LEDs are located on the edge of the PCB. The IR LEDs (TAL6200) operate at a peak wavelength of 940nm with a half angle intensity of 17°. Since the LEDs have a small angle of light intensity the direction of the signal is more linear. This focuses the user’s line of sight to a particular television. A button on the side of the headphone triggers the LEDs to output a PWM signal. The MSP430 in this application is used to receive a button press and output a unique PWM signal at carrier frequency of 38 KHz using the Sub-Main clock. Previously the design included using a 555Timer to blink the LEDs at 38 KHz, however using the MSP430 instead decreases hardware, decreases delay, and is more cost efficient.

Since the power supply to the MSP430g2231 and the RF receiver operate on a low power of 3.3V, a 3.3 voltage regulator (LP2950-50-33LPRE3) is used to step down the voltage. While a 9 V is used for the voltage divider, the MSP430 and RF receiver will run off 5 V from the RF triangulation board on top of the headphone PCB. The 5V will still be regulated by the 3.3V regulator. For circuit connections refer to Figure 4.

Fig. 4. Headphone IR emitter circuit

B. Infrared Detector

To identify a headphone is viewing a particular television; a detector board located on top of each television, receives and decodes IR signals. A vector board on each television includes a 9V power supply, 3.3 voltage regulator, IR detector module, MSP430g2231 and 2 red LEDs. The detector module (TOP32338) internally filters IR light at 38 KHz and decodes best at a wavelength of 940 nm. To ensure compatibility, the IR LEDs and detector module were chosen from the same manufacturer.

When an infrared signal is detected the module outputs low, otherwise it outputs high. For connections refer to Figure 5. The module output is connected to the MSP430 which processes the signal into an 8 bit value to identify the headphones currently viewing the television.

The MSP430 then communicates with the Stellaris located on the master board through 4 independent lines. A Ready to Send (RTS) signal is sent to the Stellaris once a headphone ID is matched to detected IR signal. When the Stellaris is ready to receive the data lines, it sends a Clear to Send (CTS) signal to the MSP430. The MSP430 then sets Line0 and Line1 which represent the bits for the headphones identified. For example, headphone 1 ID is Line0=1 and Line1=0. These values inputted to the Stellaris will be processed to determine the television audio transmitted to the headphones.

Fig. 5. Television Detector Circuit

C. Master board

The main function of the master board is to control the transmitted television audio to each headphone. There are two 4:1 MUXs on the board, one for each headphone’s audio switching. The master board receives audio from each television through RCA jacks. The sound from the

televisions is split into the inputs of each MUX. The select lines of each MUX are connected to the Stellaris. When the Stellaris receives the data from the IR detector boards, the microcontroller will output a high or low on the selector lines. In this project, the select line values 01, 10 or 11 represent audio from televisions 1, 2 or 3 respectively. The output of the MUX is connected to the data line of the RF transmitter. A 6 position DIP switch is used to control the frequency channels of the two RF transmitters. The first 3 positions on the switch are to control the RF transmitter’s channel select for headphone 1 and the last 3 positions for headphone 2. The same antenna used for the RF receivers are used for the RF transmitters. To reduce noise in audio transmission the entire PCB is placed on a ground plane.

The communication between the Stellaris and the Bluetooth module requires one set of UART pins. A bilateral communication with the tablet is possible by this module. The interface of the master board and the tablet allows the user to enable/disable headphone audio. This switching mechanism lets the Stellaris know when to enable or disable the audio through the MUXs.

D. Radio Frequency Triangulation

The system is divided into two different circuit layouts that are able to communicate with each other. This allows them to calculate the exact position of each headphone in a coordinate system.

The first circuit layout is the same for the four modules at each corner. This module consists of a powered on Xbee with a unique ID. The module participates as a beacon in which the headphone will communicate and figure out its RSSI in between the two. The schematic is shown in Figure 6.

Fig. 6. Corner Node Xbee Circuit

The second circuit layout consist of an Xbee module, an atmega328, two LEDs for testing, LM7805, LD1085v33, and a 16MHz clock. The Xbee is based on a power range of 2.8 to 3.4V in comparison to the atmega328 which utilizes 5V. The atmega328 is able to detect when a lower voltage component is plugged in so it automatically

lowers the power supply to it. So no potentiometer is needed to lower the serial data coming from the atmega to the Xbee. The corresponding circuit is shown Figure 7.

Fig. 7. Headphone Xbee Triangulation circuit

V. SOFTWARE

This project involves a variety of embedded programming and GUI. This entails creating four different programs for eight microcontrollers. The breakdown of the microcontrollers is 5 MSP430g2221, 2 Atmega328 and a Stellaris LM3S8962.

A. MSP430 Emitter

The emitter software for the headphone is programmed on the MSP430g2231 in C language. The MSP430 was debugged using the LaunchPad development board provided by Texas Instruments. The MSP430 input pin (P1.0) is connected to a button with a high to low interrupt enabled. Once pressed, an interrupt flag occurs, triggering an LED array emission on the output pin (P1.4). The IR LEDs must blink around 38KHz, for the IR detector on the television to recognize the signal. This is achieved by using the sub-main clock (SMCLK) function for P1.4, operating at 37.5 KHz.

The LEDs on the headphones transmit a Start bit followed by an 8 bit identification signal. For example, headphone 1 would transmit 0000 0001 where headphone 2 would transmit 0000 0010. Each bit is represented by an ON/OFF timing of the LED. For example, an ON bit is represented by the LED remaining ON for 25ms followed by it remaining OFF for 25ms. The OFF bit has an ON/OFF timing of 40ms/25ms respectively. Lastly, the Start bit has an ON/OFF timing of 50ms/25ms. This program is created for the user to input any 8 bit

headphone ID, and the program automatically determines the correct PWM signal to output through the LEDs.

B. MSP430 Detector

The detector software is also programmed on the MSP430g2231 in C language. This program receives an input on P1.2 from the detector module as a high (no IR signal detected) or low (IR signal detected). The input pin is initially set as a TimerA capture pin on the falling edge. This will capture the clock time when the Start bit begins. P1.2 will be set to capture on the next rising edge. The difference of this clock time and the previous clock time measures the Start bits ON time.[1] The Start time is checked to verify it is within a 5% range of 40ms. If true, the program determines the time between the following rising edges to decode the detected signal into 8 bits. A 0 or 1 bit is determined by comparing the time detected to the average ON/OFF time of both bits. If the calculated time is greater than the average the bit is 1. If less than average the bit is 0. Once the 8 bit value is reconstructed from the signal, it is compared to all headphone IDs. For a pictorial view refer to Figure 8.

Fig. 8. The IR emitter signal for headphone 1 is represented on the top and corresponding detector output to the MSP430 is shown on the bottom.

Once a match occurs the detector board will communicate with the Stellaris through RTS, CTS and 2 data lines.

C. Stellaris

The software for the Stellaris was programmed in C language. Its programming was tested on the EKS-LM3S8962 development board. The first step in the Stellaris program is to wait for a command from the tablet to set the enable line high for the MUXs. This is accomplished through the Bluetooth module connected to the UART pins on the Stellaris.

To load the program on the Stellaris, a 20 pin ribbon cable connects the master board to the development board. The 20 pin ribbon cable is connected to the Stellaris’s JTAG pins that allows for programming of the surface mounted device.

Once the first headphone is registered, the enable line to the MUX goes high. This is accomplished by the tablet sending a set of hexadecimal values to the Stellaris. An example of the value sent is FF, which means to enable headphone 1. The Stellaris also receives a disable command from the Bluetooth module changing the enable line to the particular headphone’s MUX low.

After the enable line goes high, the main loop initiates the audio switching subsystem to start. After the detector registers a headphone, it sends a high RTS line to the Stellaris. The Stellaris will read the RTS pin and if high, the Stellaris sets the CTS line high back to the detector board, which will allow the transmission of the headphone IDs. Once the headphone ID is read in, the Stellaris outputs the select lines to the MUX’s. For example, if headphone 1 looks at television 2, the Stellaris will output a 10 to the MUX’s select lines for headphone 1. The audio is then automatically transmitted to the headphones from the 900MHz transmitters.

D. Triangulation System

The software part of the triangulation system is located only at the headphone board. The Xbee modules that are located at each corner do have to be programmed to have a unique ID and to share the same baud rate and general destination address but since this can be found rather easily in [3] so we will not discuss it. First all the Xbees have their unique IDs programmed; in this case we name each Xbee at each corner MX0, MX1, MX2, MX3 respectively to their positions in the square. After doing so the programming of the corner modules was done.

The headphone part of the triangulation has an Atmega328 micro-controller that runs the algorithm. The Atmega328 has the Xbee get into API mode through the serial line. Then it calls a “ATND” commands which returns the identifiers plus the RSSI and other characteristics of all other XBees in range. Once this information is read each RSSI from each corner is read. As said before five samples are taken to minimize outliers.

At first there is no way to convert this RSSI data to distance values. Training is done in which at known distances values of RSSI are measured and recorded. All these values are compiled into a table and are hard coded to the program. A different training set has to be recorded for each different venue. Since now the software has a reference table and the unknown distance corresponding to the measured RSSI values then a closest match algorithm

is used to find the minimum distance from a known RSSI value to the unknown one.

The distances collected are use as radii to form circles by using each of the corners as centers of each circle. Circle equations are built and the intersection between three consecutive circles is measured by using simple algebra and geometry. The (x,y,z) values are collected from each of the three, and since there are four possible measurements, a simple average is used between all the x, y, and z coordinates to come up with only one point. This point is then sent via 2.4 GHz from the XBee to the application being run on the tablet. The tablet needed a way to receive data from the Xbee without interference by the other Xbees. An encrypted string was used with the following layout.

$Name,x-value,y-value^

$ = begin of message received flagName = H + the number of the headphone. Ex: H1x-value = x coordinate in metersy-value = y coordinate in meters^ = end of message received flag

E. Graphical User Interface

To maintain security of the headsets, a GUI is implemented. The main functions of this interface are to register customers who use the headsets and to track the location of each headset on a custom-built map. To best maintain mobility and the wireless function of this project, the GUI must be designed to run on a mobile device. For this project, the interface is implemented on the Toshiba Thrive, a tablet device that runs the Android Operating System (OS).

The Toshiba Thrive is equipped with a dual-core processor to handle any application with heavy processing power. The tablet also comes with USB ports and a Bluetooth module to allow different types of communication the group will be utilizing. The tablet is 10.1 inches diagonally, allowing for a comfortably large screen to read and interact with the GUI.

Google’s Android uses Java, an object-oriented programming language, along with its own extended libraries. The libraries are provided online on Google’s developer website along with examples and the software development kit (SDK) necessary for application development. This operating system was chosen due to the extensive documentation and familiarity of the programming language with the group members.[2]

The main features implemented in the Android application are Drag-and-Drop for setting up the map,

Shared Preferences to indefinitely store restaurant information (can only be destroyed upon rewriting or uninstallation), an SQLite database to store users and their registration info, a Bluetooth service to connect to the Stellaris master board, and connection to the USB port to communicate to the XBee triangulation system.

Fig 9. Google IOIO for Android

Besides the tablet, there are two pieces of hardware that interact with the GUI and communicate information back and forth. For the Stellaris board to receive “turn on” and “kill audio” commands for each headset, a Bluetooth Module (RN41) is used to communicate with the Tablet’s on board Bluetooth. This communication does not require heavy listening and will be used as a “service,” which allows a connection to remain while having low processing power. For the tablet to receive triangulation data from the XBee setup, the tablet uses its USB port to communicate with SparkFun’s Google IOIO for Android device.

Fig. 10. Software flowchart for Android application’s GUI.

Google IOIO is used to translate between Android’s Debug Bridge (ADB) interface and a microcontroller’s Serial Port Protocol (SPP). The IOIO device contains 48 Input/Output pins for a high number of peripherals to be attached; pins 4 and 5 will be used for this project, transferring data to and from the XBee module that

communicates with the rest of the triangulation system. A representation of the Google IOIO device is shown in Figure 9.

There are seven activities that make up the GUI for user interaction; the functions are best visualized in Figure 10.

The system begins with MainAppActivity, where the user has a choice of connecting to the system, setting up the restaurant’s information, or connecting to an About Us page which describes the project in more detail.

The setup for the restaurant is split into two different activities (SetupMapActivity and SetupMapActivity2), the first one takes in the name, dimension type, dimensions, number of headphones and number of tables the system uses. This information is then stored in the application’s Shared Preferences, a storage area that exists so long as the application is not uninstalled. The second activity utilizes the Drag-and-Drop method by allowing the user to place a number of tables onto a square map. Once all tables are set, the map and tables are captured onto a Bitmap, each table is named, and both the tables and map are saved as a .PNG file for later use. Once the setup is complete, the user is redirected to the MainAppActivity.

Once the map has been setup, the Connect button (previously disabled) is enabled and the user can connect to the system. Pressing the “Connect” button opens up a Bluetooth Connection to the Bluetooth module (RN41) and begins a service that runs alongside the application; allowing the connection to remain without being processor heavy. Once connection is confirmed, MapScreenActivity is launched and opens up connection to the Google IOIO device and begins communication with the triangulation system (receiving and displaying positions of the headsets). A String is given to the tablet that represents each headset’s position; this was depicted in software section of triangulation. Each headset is drawn and redrawn using Java’s Canvas method, which can draw images quickly without lagging.

At the MapScreenActivity, the user has the option to register new customers or select headsets the restaurant is using. Registering new customers sends the user to the RegUserActivity, where information such as customer name, table number they’re sitting at, headphone being assigned, credit card number and phone number are recorded. Once the information has been updated, the system stores it into a SQLite database along with the time

the registration occurred. A command is issued to “turn on” the particular headset to the Stellaris board through the Bluetooth service connection.

Selecting a headset sends the user to the HeadphoneStatusActivity, which displays the information associated with it. If the headset is in use and is registered to a customer, it pulls information from the SQLite database on that particular headset and displays that customer’s information (including how long the customer has been using the headset). The user has the option to kill the audio of that particular headset, which usually means the customer is finished and the headset is being turned in. Once selected, a kill command is sent to through the Bluetooth service to the Stellaris board.

If at any point on the MapScreenActivity, a headset that is registered leaves the boundaries of the sports bar, a security flag will be set and the SecurityUserActivity will be brought to the front. From here, the same information as the HeadphoneStatusActivity is displayed along with the customer’s credit card number and phone number. The establishment can deal with theft however they want from this point forward. This automatically sends the kill audio command to the Stellaris via the Bluetooth service.

VII.CONCLUSION

The Eye Can Hear You engineering project was hardware and software intensive. It implemented wireless audio transmission and filtering, RF triangulation, custom IR PWM emission and detection, Bluetooth communication, and an extensive Android application for headphone control and location display. The project consists of seven individual PCBs and three vector boards to guarantee component connections and accurate operation. ECHY is a television audio switching network for wireless headphones including headphone tracking, audio control and registration. Future applications could extend from restaurants to gymnasiums or industrial applications were several viewers need to switch between the audio of multiple televisions.

BIOGRAPHY

Michael Cooke is a 22 year old Electrical Engineering major graduating August 2012. He has been active in Theta Tau Professional Engineering Fraternity, American Society of Engineering Education (ASEE), Future Technical Communicators (FTC) and Student Panel for Engineering and Computer Science

(SPECS). In 2010 he worked as a research assistant under Dr. Ron Eaglin in database creation.

David Griffen is a 22 year old Computer Engineering major graduating in August 2012. He is currently interning at Campus

Crusade for Christ World Headquarters working with the Web Publishing Team, maintaining their Oracle Stellent system and their public Cru.org website. After graduation he is earning his Masters degree in Computer Engineering at the University of Central Florida with a focus on Software Design and Machine Learning.

Whitney Keith is a 22 year old Electrical Engineering major graduating in August 2012. In 2010 she was a research assistant under Dr. Brian Moore in simulating the effects

of rocket exhaust on cratering. After graduation, she accepted an Electrical and Electronic System Engineering position with Ford Motor Company in Dearborn

Michigan.

Edward Alfonso Romero Guerrero is a 22 year old Electrical & Computer Engineering major graduating in August 2012. Currently he is the lab manager of Aerolab electronic laboratory in the MMAE department at the University of

Central Florida.

ACKNOWLEDGEMENT

The authors wish to acknowledge the assistance and support of Dr. Larry Chew in providing essential parts for this project as well as Dr. Samuel Richie for guidance. We also would like to acknowledge our Review Committee: Dr. Zakhia Abichar, Arup Guha, Dr. Vikram Kapoor and Dr. Mark Llewellyn for their time and support. We would like to acknowledge Texas Instruments contribution to the project in sampling of parts and providing development boards.

REFERENCES

[1]

Buccini, Mark and Stefan Schauer. Decode TV IR Remote Control Signals Using Timer_A3. September 2001. Document.

[2] Google Developer: Android API Guides, <https://www.sparkfun.com/products/10748>[3] “Xbee radios Wireless arduino programming/serial link”. May, 2011. <http://www.ladyada.net/make/xbee/arduino.htm>