ZigBee applications - Part 6: Profiles

Manufacturer-specific profiles (MSPs) allow the OEM to define any set of clusters, endpoints, and devices. ZigBee places no restrictions on what type of data is transmitted, other than requesting that the data rate remain reasonable, so the application doesn't flood the channel.

The ZigBee Alliance assigns MSP identifiers upon requests from member companies. As explained before, San Juan Software has been assigned an MSP that we use for training and demo purposes: 0xc035. Feel free to use this MSP for your own demos, keeping in mind that it's not suitable for shipping products. At the time of this writing, there is no charge for a Manufacturer Specific Profile ID. Simply join the ZigBee Alliance and request one.

To define clusters in a private profile, start by mapping out all of the devices that will exist in the network, and all the information they must communicate. Define the payloads to be as small as possible. It is often just fine to assume some information on both sides. For example, a single command byte might suffice.

The example in this section, Example 4-10 iPod Controller, shows how to use a manufacturer-specific profile in an application. It sends a single command byte over the air on a particular cluster. That command byte is translated into a series of bytes that are sent over the serial port to control an iPod.

You've probably noticed most of the examples in this book are purely software examples. That's appropriate because this text is really about ZigBee, which aside from the radio, is all about software. But no embedded book is ever truly complete without at least one hardware project. To make it more fun, this one involves both a ZigBee network and an Apple iPod.

Seriously, if you implement this example, do be careful so you don't damage either your Apple iPod or your Freescale SRB board.

The concept is fairly simple. Use ZigBee to control an iPod (see Figure 4.23). One ZigBee node will act as an iPod controller and is wired directly to a connector plugged into the iPod dock connector port. Another ZigBee node will act as the remote control.

The following commands are implemented in this simple remote control:

• Play/Pause
• Skip Forward
• Skip Backward
• Volume Up
• Volume Down

As seen in the figure, the ZED is the remote control. This is appropriate because a real remote control is likely to be battery-operated, and so should be a ZigBee End-Device. The iPod Controller is a ZigBee Coordinator only to keep the example small, with only two nodes. This same example could work across any size ZigBee network, and the iPod controller could be an RxOnIdle ZED, or a ZigBee Router.

To obtain an iPod connector, I used an on-line store headquartered in Sweden (strange how the world is so small these days) at http://home.swipnet.se/ridax/connector.htm. They also have a U.S. office and phone number.

To obtain more information on the iPod connector and the commandset available, take a look at my old favorite, Wikipedia: http://en.wikipedia.org/wiki/Dock_connector, or go to http://ipodlinux.org/Dock_Connector.

To prepare an SRB board for the iPod Controller node, remove the battery pack from the back. There is some double-sided sticky tape, and also the thin wire connection between the battery pack and the board. I simply used my hands and applied pressure. The SRB board doesn't care if the battery pack is gone as it can also receive power through the USB connector.

You will also need a soldering iron. I used my own, but you may have a coworker or friend who can do the soldering.

Assuming you've been following along with examples using the Freescale development kit, the NSK, this example can be completed with the following steps:

1. Buy a connector (this may take a few days to deliver)
2. Buy an iPod (Okay, you probably already have one)
3. Open the case and remove the battery pack from the SRB
4. Solder the two-wire connector to the SRB as pictured
5. Program the modified SRB as the Controller, and another SRB as the remote
6. Enjoy controlling the iPod with the remote SRB board

Pictured in Figure 4.24 are an SRB board on the left, and an iPod on the right, with the dock connector hardwired to the SRB board and plugged into the iPod.

The black wire is the ground. Any ground will do, but I used the ground from the BDM (J101, pin 2). Only the Tx wire needs to be connected for this demo, as the SRB will control the iPod, but not receive any information from it. I've included a close-up picture of the soldering in Figure 4.25.

To run the example, compile and download the following two projects into two SRB boards onto the one which you have soldered the iPod connector:

• Chapter04\Example4-10iPodController\SrbZciPodController
• Chapter04\Example4-10iPodController\SrbZediPodRemote

These operate on channel 25, PAN ID 0x1aaa, but any set of channels or PAN IDs will do. The application is the same whether it is on the controller or the remote. If the application receives an over-the-air command, that is, a data indication, it sends a corresponding set of bytes to the serial port. If a button is pressed, it sends the command over-the-air via a data request to node 0x0000.

Assuming node 0x0000 for the destination (the ZC) made the application a little simpler, with a bit of work the application could be made more robust complete with binding.

I also show a close-up of the wiring configuration in Figure 4.25. Make sure to solder the red wire to the Tx pin on the UART (TP131 at the back of the SRB board). Make sure to solder the black wire to ground. I used pin 2 of J101, but any ground pin will do.