XBee ZB Pro Upgrade Pin Sleep Trick

While developing the XBee-API 0.5 release, I upgraded my series 2 (ZNet 2.5) radios to ZB (ZigBee PRO) firmware by following the Digi conversion instructions

I was able to perform the firmware flash for both radios: "API coordinator (1941)" and "API End Device (2941)", but when I attempted to read the End Device using X-CTU, I got the following error:

"Failed to enter command mode
Unable to read Version (ATVR)
Read parameters.. Failed."

After a few more attempts, the read succeeded but when I clicked "write" to save my configuration I got a similar error:

"Getting modem type....OK
Programming modem...Lost communication with modem
Write Parameters...Failed"

Woe ensues. As it turns out, the default sleep option for "API End Device (2941)" firmware is SM=4 (Cyclic Sleep); the errors occur because the radio is periodically going to sleep and waking up. Unfortunately SM=0 (No Sleep) isn't even supported in this firmware, but there is a solution. To simulate No Sleep, configure the radio to SM=1 (Pin Hibernate), and then connect Pin Sleep (pin 9) to Ground (pin 10). Credit goes to Hans (XBee-API user) for this idea.

Now to program the radio we still have to fix the sleep issue. To do this we can use the Reset pin (pin 5). The Reset is activated by connecting the Reset pin to Ground (pin 10), and then disconnecting. If you have a toggle switch handy you'll want to wire this to pin 5 and pin 10. (Remember if you are using, XBee Explorer USB, there are two extra pins (GND and 5V), as shown in the diagram)



Now toggle the switch on/off just before performing the X-CTU action (e.g. read/write). Once you have configured the radio to Pin Hibernate mode and grounded pin 9, the radio won't go to sleep and you won't need to use the Reset pin anymore.

XBee Communication over Google Talk

I had been kicking this idea around since early last year but progress was slow until recently. So what happens when we have stretches of frigid, bleak weather? I end up coding, a lot. The end result is XBee-XMPP, which I released a few weeks ago on Google Code.



This project builds on XBee-API and provides a solution to talk to your XBee network from anywhere on the internet, using XMPP.

Now you can sit back in your favorite chair or couch and write code to communicate with your XBee radios, without cables, and/or breadboards dangling off your notebook. You can even share your XBee network with your friends. It doesn't even matter if your application is behind a firewall (e.g school/work/home), because as long as you can reach the XMPP server (Google Talk or Openfire), you can talk to the XBee network. With this solution, your XBee applications run in separate processes, so they can stopped, started, upgraded etc, all without affecting your other applications.

This project uses Smack for XMMP communication. Initially I'm supporting Openfire and Google Talk, but any XMPP service should be possible. Google Talk is recommended for getting up and running quickly because you don't need to setup a server; you just need two Google Talk accounts.

Arduino LED Color Picker

After experimenting with an RGB LED for a while, I became interested in the idea of using a color gradient to control the LED. I search around a bit for a color gradiant library and finally settled on colorpicker, a subproject of colorchooser (scroll down the page for colorpicker). This library is surprisingly easy to integrate with and allows you to receive color events in real-time, as you drag the mouse around the gradient.

Since this solution is written in Java and uses the same serial library (RXTX) as Arduino, it will run on any platform that Arduino supports (Windows/Mac/Linux etc.). I have included RXTX libraries in the download so it will run on any of these platforms, out-of-the-box (box not included).

Here's a quick video of the application in action:



The application consists of Java application that serves as the colorpicker interface and an Arduino Sketch that receives RGB colors and applies them to the PWM pins

The basic process flow of the Java application is as follows:

- Open serial port to Arduino

- Initialize colorpicker component and register an event handler

- (In forever loop)

- Wait for colorpicker event.

- Send color to Arduino

- Wait for reply from Arduino (ACK)

The colorpicker runs in a separate thread and sends color events to the main thread.

The Java application sends the RGB colors in a sequence of four bytes: red, green, blue and a EOT byte. The EOT byte signals the end of a color sequence and instructs the Arduino to process the color. Since a byte has 256 values and we need all of them for the color values, I created a escape byte (0x2) to distinguish the EOT byte (0x1) from the color value (0x1). Any time a color value of 0x1 or 0x2 is sent, it is preceded by a escape byte and XOR'd with 0x20. When the Arduino receives the data via Serial.read(), it performs a corresponding XOR operation to un-escape the bytes.

Once the Arduino processes the color, it sends an ACK byte back to the Java application, so that it can send the next color. Without the ACK byte, we run the chance of overflowing the buffer by sending color events faster than the Arduino can process them.

Here's the Arduino sketch:

// Adjust as necessary to match your RGB LED.  Remember to only use the PWM pins
int redPin = 11;
int greenPin = 10;
int bluePin = 9;

// Indicates what color we are reading next; 0 = red, 1 = green, 2 = blue
int pos = 0;

// red PWM value
int red = 0;
// green PWM value
int green = 0;
// blue PWM value
int blue = 0;

// indicates if next byte should be unescaped
boolean escape = false;

void setup() {
  pinMode(redPin, OUTPUT);
  pinMode(greenPin, OUTPUT);   
  pinMode(bluePin, OUTPUT);
  
  Serial.begin(9600);

  // turn on LED on low brightness  
  analogWrite(redPin,   16); 
  analogWrite(greenPin, 16); 
  analogWrite(bluePin,  16);  
}

void loop () {
    
    while (Serial.available()) {
      int rgb = Serial.read();
      
      if (rgb == 1) {
        // end of RGB sequence byte
        // reset pos
        pos = 0;
    
        // process this color
        analogWrite(redPin, red);
        analogWrite(greenPin, green);
        analogWrite(bluePin, blue);
    
        // Send ACK byte so Java app can send the next color
        Serial.print("k");
        Serial.flush();
        
        // get next byte
        continue;
      } else if (rgb == 2) {
        // escape byte
        escape = true;
        // discard byte and read next byte
        continue;
      }
      
      if (escape) {
        // unescape byte
        rgb = 0x20 ^ rgb;
        // reset escape
        escape = false;  
      }
      
      switch (pos++) {
        case 0:
          red = rgb;
          break;
        case 1:
          green = rgb;
          break;
        case 2:
          blue = rgb;
          break;
      }
    }
}

To run the app, first download the project from my Google Code project. I've included the full Java source code and everything necessary to run the app, sans Java.

Next, connect your RGB LED to the Arduino PWM pins, as specified in the Arduino sketch. Be sure to use appropriate resistors so that you do not draw more current than the Arduino can supply. If you need a RGB LED, here's a basic one offered by SparkFun . You could also use separate Red, Green and Blue LEDs and diffuse the colors with something like a paper box.

Now upload the sketch to your Arduino.

If you don't have Java 1.5 or later, now would be a good time to get it. You can find out by opening a command prompt/shell and typing "java -version" If you see something like this then you are all set:

java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)

Before running the Java application you need to open the run script for your platform and specify the COM port of your Arduino:

Windows: ledcolorpicker.cmd
Mac/Linux: ledcolorpicker.sh

The COM port should be the last argument on the line that starts with "java"

Now run the script for your platform:

Windows: double-click on ledcolorpicker.cmd (note: if the window closes immediately, open a command prompt and run the script again to get the error)

Mac/Linux: First you probably need to make it executable: "chmod u+x ledcolorpicker.sh". Now run the script "./ledcolorpicker.sh"

The LedColorPicker application should now start up and be ready to go.

Based on my results, the Arduino processes colors in about 16ms -- that is time it takes to send a color to the Arduino and receive an ACK @ 9600 baud. I've found that the Arduino can process color events almost as fast as the colorpicker can generate events. In my limited testing, only less than 2% of color events were discarded because the Arduino was busy processing a previous color. You could use a higher baud rate but with this level of performance it's not necessary. This translates to the Arduino processing about 30 colors changes per second -- not bad.

You may have noticed that we are tethered to our computer in this configuration. The good news is it's possible to make this solution wireless with minimal effort, using with XBee radios. Using the Arduino XBee Shield configured in transparent mode, you could put your LED across the room or anywhere within range and control it from your PC. In this configuration you would need two XBee radios, 1 Arduino XBee Shield and 1 USB-Serial device with XBee socket, such as the SparkFun's XBee Explorer.