IPC Class Notes, Communicating Wirelessly - November 11, 2009

In this week’s Introduction to Physical Computing class we had a brief discussion regarding microcontrollers, followed by and overview of how to use serial communications via wireless, then we briefly reviewed final project ideas.

Microcontrollers
When designing our final project Tom stressed the importance of taking into consideration the different form factors of Arduino and other microcontrollers available for our projects. These include:

The Arduino Family
There are several Arduino form factors available, and all are based on an AT Mega chip set. the Duenovemille is the standard unit that we have been using to date; the Nano is another standalone unit that features the same chip in a smaller form factor with a reduced number of pins; the Mini and Mini Pro are other small form factors that are designed to be mounted to a breadboard and features a chip with a bit less memory; the Mega is a larger unit that features considerably more memory and a large number of pins; lastly, the Lillypad is a chip designed for wearable computing projects.

Funnel IO and Gainer
Funnel IO (FIO) is an Arduiono clone that features an AT Mega and is integrated with an XBee on the back. Developed by Shigeru Kobayasho, FIO was created to work with Processing, ActionScripting, Max/MSP, Gainer and Wonderfl. Similar to the Arduino, FIO was created to enable artists and designers to integrate physical computing into their projects. Please note that the content on the Gainer website is mostly only available in Japanese – that said, it can be entertaining to use Google translation to read through it.

Illuminato X Machina
A new addition to the microcontroller offerings is the Illuminato X Machina. This chip attempts to add more capabilities and power to the world of microcontroller, without increasing the complexity of the development environment. This chip has an interesting design that is based on a cellular network. It allows users to increase the processing power by setting up networks of microcontrollers.

Serial Communications Using Wireless
Serial communication protocols are used by a large variety of components, including RFID, displays, motor and sensor controllers, to name a few. Wireless modules, such as the Xbee, connected to computers and Arduinos using serial.

To date, all of our explorations into serial protocols have focused on asynchronous types of communications. In order to use the XBee we need to use synchronous communications instead. Below is a brief refresher on these two concepts. It is important to note that many wired components also work with synchronous connections.

Asynchronous Communications
In asynchronous communications the connected devices each have their own clocks and send messages back and forward in an uncoordinated fashion, from a clock perspective. It is important to note that a programmer can use a coordination mechanism, such as call-and-response, to manage the communications.

Devices that are linked for asynchronous communications share three connections: two transmit and receive connections (each one set to an alternate direction), and a common ground.

Synchronous Communications
In synchronous communications the devices share a clock and send their messages in coordination with the clock pulses. Networks of devices that are connected synchronously, always feature a master and a set a slaves. The master is the device that sets the clock for all others.

Devices that are linked for synchronous communications share four connections: a Master In Slave Out (MISO) connection, a Master Out Slave In (MOSI) connection, a clock connection, and a common ground.

Components that can use synchronous serial communication have a pin called Chip Select. This pin enables the master device to connect to multiple devices using a single clock, MOSE and MISO pins, as long as it is directly connected to each slave chips Chip Select pins. In these types of circuits synchronous serial devices will only communicate on the MISO and MOSI pins if the status of the Chip Select pin is properly set.

Back to the Xbees
When setting up an Xbee on an Arduino you need to use the serial transmit (TX) and receive (RX) pins from each device. This will enable information to flow to and from both components. On the Arduino IO pins 0 and 1 are the RX and TX pins. It is important to disconnect the Xbee when uploading a program via serial to your Arduino. The reason being, if the Xbee is connected to the serial port then the Arduino can’t use this port to connect to the computer.

If multiple Xbees are connected to the same multimedia computer (or master) then each one of the chips will have its own address. Messages can be sent to a single address, or can be broadcast to all Xbee devices.

To set up an Xbee you first need to set it up using USB. For this you will need a USB to serial adapter for the Xbee, which converts data from traditional serial protocols (TTL and R-232) to the appropriate USB protocol. The most common adapter used for this task is the Xbee/USB breakout board (also called XB explorers).

Xbees use the AT Command Set, which was originally designed to drive modem communications. This protocol is widely known, and has been used for a long time. There are two different modes of communications used in the AT Command Set (and most similar protocols for that matter):

• Command Mode: communications to the modem.
• Data Mode: communications through the modem.

There are two different types of Xbees. They are not able to work together because they have a different stack above the AT Command Set.

• Series 1 uses 802.14.5 command set. This protocol is more limited than the series 2 but it is also much simpler. It provides more than enough functionality for most types of uses and is the right way to go for most applications.
• Series 2 uses a command set that supports mesh networking. It is much more complex to use than series 1. Mesh networks are made up of devices configured as “controllers” (c), “routers” (r), and “end-points” (e). The “routers” essentially act as post office boxes that hold and distribute messages to the end point. Since the end points don’t always have to stay on this is a more energy efficient system.

When you first connect an Xbee the device is in data mode. In order to enter into command mode you need to use a variation of the standard AT Command Set protocol: “+++” (rather than the protocol standard of “+++\r”). Here is an of the options that you need to set-up in order to get Xbees to start talking politely:

• Address of Xbee chips (destination)
• Address of multimedia computer (source)
• Pan ID that enables to join Xbees into groups, so that different groups of Xbees don’t conflict with one another. Check out the pan ID list available on the Physical Computing website at ITP to select an unused port.

To get two Xbees to talk to one another without including an Xbee attached to a multimedia computer the Xbees need to be set to API mode. This mode uses a totally different protocol that is not based on the AT Command Set.

When using Xbees it is advisable to use a handshake (call-and-response) method so that we don’t encounter delays associated to buffer issues. When using multiple Xbees the handshake logic of the code is the same as the example we previously explored in class, for the most part. The difference is that we need to add logic on the receiving end to confirm where the data was sent from, and to determine where to send the next request.

Bluetooth
Bluetooth is another wireless protocol that is often used for wireless communication. However, Bluetooth only supports one to one communications, so all Bluetooth devices can be connected to a multimedia computer only and not to one another. Bluetooth also sets up sessions when they connect with a device, which requires a few seconds for initiation and closing a connection.