XBee Supply Voltage monitoring (2)

Here are the results of the test i started 3 days ago. After 3 days of monitoring the XBee supply voltage the alkaline batteries were empty and with a bit of tweaking i got the data out of the logs and into an Excel sheet so i could create a chart:

XBee Supply Voltage

XBee Supply Voltage

OK, this looks good and it’s easy to do; all you need are some changed settings on the XBee, a Domotica system that can fire the ‘IS’ remote AT Command to your XBee and your done. Well, almost 🙂

The JeeNode has been running a small sketch that transmits a dummy string every 5 seconds; without any sleeping and also keeping the XBee on all the time:

#include <NewSoftSerial.h>

#define SERDBG 1
NewSoftSerial XBSerial = NewSoftSerial(2, 3);

int CTSpin = 7;
int XBpin  = 6;

static void Send () {
  // send a dummy string
  XBSerial.print(millis());
  XBSerial.print(" ");
  XBSerial.println("XBeeaaaaaa");
#if SERDBG
  Serial.print(millis());
  Serial.print(" ");
  Serial.println("XBeeaaaaaa");
#endif
}

void setup() {
  // setup XBee
  pinMode(CTSpin,INPUT);
  pinMode(XBpin,OUTPUT);
  digitalWrite(XBpin,LOW);
  digitalWrite(CTSpin,LOW);
  delay(10);

  XBSerial.begin(9600);
#if SERDBG
  Serial.begin(9600);
#endif
  // give XBee some time to join PAN
  delay(5000);

  // let the world know we're here
  XBSerial.println("[XBeeVoltage]");
#if SERDBG
  Serial.println("[XBeeVoltage]");
#endif
}

void loop() {
  delay(5000);
  Send();
}

The JeeNode stopped working at around 2/3 of the horizontal axis, so after 48 hours or so where the voltage had already dropped to 2,64 V. The XBee is still working as i write this, with a voltage of 2,3 V. I wonder how long it takes for the XBee to give up too…

Conclusion: this can definitely be used as a way to remotely monitor my battery powered sensors; Yippee!

XBee Supply Voltage monitoring

One thing i would really like, is being able to monitor the voltage the JeeNode and XBee are running on. Now the XBee has a %V command, specially for reading the voltage on the Vcc pin. So let’s see of i can use this.

The first thing i noticed was that the XBee i configured with the AT End Device firmware, didn’t respond to the %V command. Hmm, correct; the manual was very clear about it: the %V command is only supported by a Router  and not by a Coordinator or an End Device. And it’s those End Devices  (which will run on batteries) that i want to monitor…

OK.. next command to have a look at was the ‘IS‘ command, which stands for Force Sample; this command forces a read of all enabled digital and analog input lines and a small comment told me it could also return the supply voltage: “Analog samples are ordered sequentially from AD0/DIO0 to AD3/DIO3, to the supply voltage.”  So lets try this one, shouldn’t be to hard i guess?

So i added support for this command to my API and started sending frames to the XBee:

Sending frame:7E 00 0F 17 01 00 13 A2 00 40 33 1F 7A A2 ED 00 49 53 FB

I won’t go into detail of every byte in the frame above, but the 2 bytes marked in red are the ASCII codes for ‘I’ and ‘S’: yes, ‘IS’, the command we want to be executed on the remote XBee. The response that came back from the XBee was encouraging, however, no supply voltage was present, only the values of some random Analog input lines i enabled:

Rcvd Frame:97 01 00 13 A2 00 40 33 1F 7A A2 ED 49 53 00 01 00 00 02 02 09
FrameID=1, Command=IS, Status=0, Command Data size = 6 (01 00 00 02 02 09)

With the help of an example i found out the meaning of the Command data:

IS response example

IS response example

OK… the frames that were being received looked nice, but it’s not what i want… where’s the supply voltage? The example above doesn’t show it either.. but it must be possible, right?

After searching for more than an hour, i suddenly bumped upon a setting in the X-CTU tool (in the I/O Sampling section), that had the following description:

Configure the supply voltage high threshold.  If the supply voltage measurement equals or drops below this threshold, the supply voltage will be included in an IO sample transmission.  RANGE:0-0XFFFF

Aahh, that must be it… this setting has a default of 0, causing the supply voltage to never be included in an IO sample! I set the value to FFFF, disabled all other I/O lines on the XBee et voila:

Rcvd Frame:97 01 00 13 A2 00 40 33 1F 7A A2 ED 49 53 00 01 00 00 80 0A BC
FrameID=1, Command=IS, Status=0, Command Data size = 6 (01 00 00 80 0A BC)

This means there is 1 sample set, containing the supply voltage, and the value is: 0ABC.

Multiply this with 1200/1024 and you get the supply voltage in mV:

($0ABC =) 2748 * 1200/1024 = 3220 mV. Great!

Tomorrow i’ll add some code to my HA system to periodically send an IS command to this XBee and store the results. And then just wait and see what happens when i let a JeeNode and XBee running on alkaline batteries 24/7…

New motion sensor in use

After my problems with the MS13 sensors yesterday, i managed to find some spare time (even though, or maybe because it was father’s day) to write a sketch for the new motion sensor i created during the last couple of weeks. Always taking one step at a time, i located the first prototype of this sensor at a place where i can see the enclosure LED from the living room: i want to know how it performs…

New motion sensor

New motion sensor

Now powered by 3 rechargable NiCd batteries and with all hardware nicely put away in the enclosure. In due time the enclosure will be moved out of sight so only the PIR will be visible. I’ve decided to use 3.5 mm jack plugs to be able to disconnect the enclosure from the sensor, so i can easily take the enclosure back to my office, because i don’t think the JeeNode is already running the final version of the ‘PIR’ sketch… 🙂

A new class, 2 database records and 1 line of code were enough to get the sensor working in my Domotica system:

procedure TAMN31112.ProcessInterfaceData;
begin
  Pin(1).AsBoolean:= (O.Data[1]='1');
end;

The new PIR can be viewed from my website (it’s called BP PIR):

Battery powered PIR

Battery powered PIR

The sketch is still under development; for instance, how much difference would it make if i change the DigitalRead() into a bitRead()? I’ll have to read more about that on JeeLabs … Other questions are: should i increase the heartbeat interval (currently 45 seconds) or the Motion report interval? Can i create some sort of battery power monitoring with the XBee? But that will all be investigated when i’ve finished building my second motion sensor based on JeeNode and XBee..

Motion sensor in next stage

This weekend i spent some time to make the experimental PIR sensor setup i made some time ago, a bit more permanent. Ingredients:

Enclosure modified with hobby knifeThe enclosure i used this time is a bit different from the enclosure i used on a previous occasion. This one lacks the inner ribs and opening and closing is a bit harder: for opening the enclosure you need to put a screwdriver between the 2 halves and twist it to get the enclosure open.  The first thing i did was making my life easier by removing the ribs that keep the 2 halves together on one side of the enclosure. Some more modifications here and there now make it possible to open the enclosure without any additional tools, but still will not open by accident.

PIR enclosurePIR enclosure

I drilled a 10 mm hole into the PIR enclosure so that the PIR fitted nicely through the top plate; a drop of super glue on the inside did the rest. There was plenty of room for the 100k pull-down resistor inside the PIR enclosure so i soldered it to the PIR there. An extra hole of 4 mm and a cable tie for the wire completed the PIR box.

JeeNode, XBee

JeeNode, XBee

This being my first motion sensor built this way, i added a LED to be able to see what the XBee radio is doing; is it still transmitting or not, when, how often, etc. ? Maybe this is overkill, but when this sensor is placed somewhere in the house with no computer screen nearby, it can be very handy to see if the sensor is still functioning instead of running to and from the nearest screen…
If the flickering of the LED is to visible or annoying in the future, i can always disable it or make it invisible by a piece of tape over it; but for now, this LED seemed like a good idea to have. The LED lights up when the XBee is on and from the duration that the LED stays on i can see what’s happening; whether it’s transmitting (very short durations) or having PAN trouble (long).

The software part of this sensor will be the most time consuming of it all i guess. Since i want it to be battery powered, i’ll have to consider what is relevant information for my Domotica system, and when it is. In fact, the only thing that really matters is one single thing: fast motion detection! All the rest is less important.
Cause what do we Domoticans use this motion detection for? To turn things ON… not OFF; at least, i don’t.

Further more, a quick look in my events history tells me that from 01-04-2010 till today i missed (my 433 MHz RFXCOM receivers, i mean) a total 869 ‘OFF’ transmissions (meaning “no motion”) from my 10 MS13 motion detectors. That’s way to much to be called reliable! So my system already has the capability to deal with this situation of missing ‘OFF’ transmissions; when a MS13 hasn’t reported neither an ‘ON’ nor an ‘OFF’ for a specific time interval, i set the motion sensor back to ‘OFF’ in software.

So.. i could as well do without this ‘OFF’ completely; i don’t use it as a trigger, so why send this non-information anyway?

What i do want to have is a heartbeat, every 90 seconds or so. And i would like to have an ‘ON’ being sent with a specific interval when motion is detected continuously. That’s what I’ll be working on in the coming week.

To be continued.

JeeNode/ZigBee pressure sensor closed

Now that my Zigbee/Jeenode equipped pressure sensor is working for 3 months without any problems, it was time to leave the breadboard stage and move on to something more permanent. While ordering new Jeenodes at Jean-Claude Wipplers shop, i stumbled upon a post (i should read his daily weblog more often!) that showed me just what i needed: an enclosure that looked just right for this job. I ordered the Jeenodes, 2 enclosures (1 extra for when i mess up the first one and don’t want to wait for a second delivery..) and some other handy stuff.

First i sawed off the part of the PCB that i didn’t need, to decrease it’s size.

JeeNode PCB without RF part

JeeNode PCB size reduction

Guess what? Now the length of the PCB equals the internal width of the enclosure! Nice… I still had some battery holders laying around that also fitted quite well:

Enclose, batt holder and JeeNode

Enclosure, batt holder and JeeNode

I didn’t want to leave off the FTDI headers, so i used 6 straight headers and removed the plastic strip from the headers after the headers were soldered onto the PCB. With the plastic headers left on, the completed PCB was just a bit to wide for the enclosure, which caused tension and the enclosure wouldn’t close well anymore.

Next item that had to be prepared, was the XBee Breakout Board. Normally the top of this Breakout Board contains the 2mm XBee headers and the 0.1″ spaced headers are at the opposite side. I removed the bottom headers i soldered in when i used this board for other purposes and soldered 6 wires on it from the top, only for those pins i really needed:

XBee Breakout Board

XBee Breakout Board

Pin 1 (labeled Vcc) for Power, Pin 3  (labeled DIN) for transmission, Pin 9 (DTR) for controlling Sleep mode, Pin 10 (GND), Pin 11(CTS) and Pin 12 (ON) for the LED. This makes the Breakout board a lot thinner and the wires are coming out between the board and the XBee module.

After soldering the wires coming from the XBee board to the JeeNode, drilling a hole for the LED (which blinks when a pressure sample is being sent), soldering the wires and gluing the battery holder into the enclosure, it looked like this:

Almost done!

Almost done!

The FTDI headers are very handy now, for uploading the sketch with the JeeNode already inside the enclosure; cause all you have to do is open the enclosure, gently lift up the left side of the JeeNode and connect the cable. So whenever i need to upgrade the JeeNode, i don’t have to worry about connecting issues.

FTDI cable connected to the JeeNode

FTDI cable connected to the JeeNode

Now all there was left to do was moving the XBee module and the Pressure Plug from the Breadboard to their new ‘home’, add 4 batteries, click on the other half of the enclosure and.. my first WAF certified sensor was born!

Zigbee Pressure sensor

The power of Arduino and Zigbee

Today i had some spare time to combine a few of the things i’ve been working on lately:

  • My Zigbee API;
  • Arduino;
  • Pan & Tilt mechanism

I wanted to create a small executable that would enable me to control the position of the 2 servo’s.

XBee module

I started with programming the XBee: Zigbee End Device AT firmware, the right PAN, Node Identifier ED5 (as in End Device 5), Sleep Mode=1 (Pin Hibernate). I put the module on a breadboard by use of a Breakout Board. Grounded pin 9 and used the 3.3V output of the Arduino to power the module.

Arduino

I strapped the Arduino Duemilanove to the same breadboard and wired the 2 servo’s. Pins 9 and 10 of the Arduino are used as PWM output for the 2 servo’s. Arduino pins 2 & 3 were connected to the DIN and DOUT pins of the XBee module.

Sketch

Now it was time to write a sketch that would receive commands from the XBee and move the servo’s accordingly. The sketch is a real quick and dirty one, low on error handling and validation. I made up a small ‘protocol’: commands have to end with the exclamation mark (“!”) and can be either 1 or 2 characters long.

P+! would Pan right 3 degrees, P-! would Pan left 3 degrees, T+! would Tilt up 3 degrees and so on. H! is the command to go back to the Home position. Of course you can extend this as much as you like, e.g. add absolute positioning, presets, you name it.

This is the sketch:

#include <NewSoftSerial.h>
#include <ServoTimer1.h>
#include <PString.h>

ServoTimer1 PanServo;
ServoTimer1 TiltServo;

int PanAngle = 90;
int TiltAngle = 90;
byte DeltaPan = 3;         // move 3 degrees
byte DeltaTilt = 3;        // move 3 degrees
char cbuffer[40] = "";     // receive buffer
NewSoftSerial XBSerial = NewSoftSerial(2, 3);
PString buffer(cbuffer, sizeof(cbuffer));

void setup() {

  XBSerial.begin(9600);         // set up XBee at 9600 bps
  delay(10000);                 // wait 10 sec. for possible joining

  PanServo.attach(9);
  TiltServo.attach(10);

  PanServo.write(PanAngle);
  TiltServo.write(TiltAngle);
}

void waitforcommand()
{
  while (true)
  {
    if (XBSerial.available())
    {
      int c = XBSerial.read();
      if (c == 0x21)     // command terminator = "!"
      {
        break;
      }
      else
      {
        // add to buffer
        buffer.print(c,BYTE);
      };
    };
  };
}

void loop() {

  buffer="";
  waitforcommand();

  // what's the first character?
  switch (buffer[0])
  {
    case 0x50:             // P for Pan
      {
        // what's the next character?
        switch (buffer[1])
        {
          case 0x2B:       // +
            PanAngle += DeltaPan;
            break;

          case 0x2D:       // -
            PanAngle -= DeltaPan;
            break;
          };
          break;
      };
    case 0x54:            // T for Tilt
      {
        // what's the next character?
        switch (buffer[1])
        {
          case 0x2B:       // +
            TiltAngle += DeltaTilt;
            break;

          case 0x2D:       // -
            TiltAngle -= DeltaTilt;
            break;
          };
          break;
      };
    case 0x48:            // H for Home
      {
        PanAngle=90;
        TiltAngle=90;
        break;
      };

  };

  // check boundaries for Pan
  PanAngle=(PanAngle < 0)?0:PanAngle;
  PanAngle=(PanAngle > 180)?180:PanAngle;

  // check boundaries for Tilt
  TiltAngle=(TiltAngle < 90)?90:TiltAngle;
  TiltAngle=(TiltAngle > 180)?180:TiltAngle;

  // Set dervo's accordingly
  PanServo.write(PanAngle);
  TiltServo.write(TiltAngle);

}

PC software

Next item was a small program that would use the API to address the XBee module.

XBee servo control

XBee servo control

4  buttons for Left, Rigth, Up and Down, a Home button and a button to connect to the Zigbee network. Not very spectacular, I’d say.

There are 2 important API functions that are used to communicate with the Zigbee module:

  • Node Discovery
  • XBee Transmit Request.

The code that is executed when the “Connect” button is pressed, sends out a Node Discovery command. This will trigger all joined Zigbee modules to respond with information about themselves, like 16- and 64-bit address, node identifier and some more interesting stuff. The code goes something like this:

  XB:=TXBEE.Create(14,9600);
  XB.Open;
  gXBeeModules.Clear;
  cmd:=TXBee_NodeDiscover.Create('');
  XB.SendPacket(cmd.GetPacket);

The Node Identifier is used to see if the Zigbee module that is connected to the Arduino, is “in the air”. Cause it doesn’t have to be, it could be disconnected from power or whatever…

When the Zigbee module with Node Identifier “”ED5” has responded, the 5 buttons are enabled and clicking them will move the servo’s. This is done with the XBee Transmit Request function; a string is being sent to the XBee and the XBee will take care of transferring it out on the UART.  Below the code for the “Home” button:

i:=gXBeeModules.Indexof('ED5');
if i >=0
then begin
Module := TXBeeModule(gXBeeModules.Objects[i]);
Addr16:= Module.Addr16 ;
Addr64:= Module.Addr64 ;
TR:=TXBeeTransmitRequest.Create(1,Addr16,Addr64,"H!");
X.SendPacket(TR.GetPacket);
end;

Et voila, the servo’s start moving!

To see how (good or bad) it works, i’ve made a small video.
The power of Arduino and Zigbee!!!

ATMega328 and its Watchdog Timer

Now that i managed to put an XBee ZB module to sleep, all i had left to do was being able to put the RBBB to sleep for a certain amount of time (and have it wake up again!).  It would be very nice if i could use 2 triggers for waking up the controller: based on a predefined interval and by some external source (for example an attached motion detector that detects motion).

Zigbee module

Low-power Zigbee & Arduino

Both are actually equally important, so i tossed a coin with the outcome that i started with trying to accomplish to wake up the RBBB on a predefined interval. I found an article that pretty much did what i wanted. The maximum time that the Watchdog Timer can power down the microcontroller is 8 seconds, after which it will wake up again and carry on with it’s job. I modified some things so that the power down routine is called multiple times, which results in a power down mode in multples of 8 seconds. Currently the wake up interval is set at 32 (4*8) seconds and it has run flawlessly for 16 hours now. I still have to dig in deeper to the Watchdog code see if my ‘modifications’ can be made more efficient, but for now this will be OK.

Now i wonder what the power consumption of this combination of RBBB and Zigbee module is… should i let it run on a battery and wait till it stops? How long will that be…. no; i think it’s better to find a way to estimate battery life by actually measuring the power consumption. That will probably mean i will need extra hardware and tools.

Sleepy Arduino and Zigbee

While working on the experiments I’ve done in the past months with the Arduino Duemilanove, RBBB, XBee Series 1 and 2 modules the thought of a wireless, battery powered, ‘intelligent’ sensor kept me busy.

RBBB controlling a XBee ZB module

RBBB controlling a XBee ZB module

Finally the time had come  to do some experiments  in that direction. I’ve found several very well written articles, all by Jean-Claude Wippler regarding Low-power techniques. This was a very good starting point; one of the things that i concluded is that running on 3.3V is the best choice: it seems it’s much easier to interface with sensors at 3.3V then 5V. So i really gotta have me some JeeNodes soon now! 🙂

But it wouldn’t hurt to already start searching the net for code that would support bringing the ATMega to a state in which it would consume much less power.  I had already found a way to bring an XBee module to deep sleep by setting Sleep Mode (SM) to 1 and grounding pin 9, so now it was time to start sketching and produce something that could put both the RBBB and the attached XBee to sleep for a fixed period, wake them up, take samples of whatever sensor is attached, send the data to the Zigbee Coordinator and go back to sleep again. I didn’t want to use any external trigger, so the solution had to be found inside the MCU itself.

Putting XBee to sleep

First i wrote a sketch that periodically woke up the XBee, send some data and put the XBee back to sleep. That shouldn’t be that hard.  How wrong could i be….

The job to do comes down to the following sequence:

  • wake up the XBee (use a Digital Output from the RBBB to set XBee pin 9 low);
  • wait for the XBee to be ready (CTS pin to go low);
  • send some dummy data;
  • wait a little more and put the XBee back to sleep (set XBee pin 9 back to high);
  • delay the loop for a number of seconds.

At first run all worked fine. However, after increasing the interval at which the job listed above were to be executed, i started losing packets. Because i enclosed a counter value into the sent data, i could see a very strange behavior: depending on the interval i saw packets coming only once every 2 or 3 times a packet was sent… What’s that?? By playing around with the interval i could determine that something strange was happening when the interval was set above 5 seconds. Why ? It took me some time to figure this out.

Sleeping XBee

Sleeping XBee

I  remembered the 5 seconds to be the default value for the “Time Before Sleep” (ST) Command. But this Command and the value set, are only applicable for Cyclic Sleep End Devices. And indeed, changing the Time Before Sleep didn’t make things better. OK, so now it was time to start reading the manual really well 🙂

And there it was: the “Child Poll Timeout” must be what is bugging me. This is what the manual has to say about Child Poll Timeout:

“Router and coordinator devices maintain a timestamp for each end device child indicating when the end device sent its last poll request to check for buffered data packets. If an end device does not send a poll request to its parent for a certain period of time, the parent will assume the end device has moved out of range and will remove the end device from its child table. This allows routers and coordinators to be responsive to changing network conditions.”

So, if an End Device doesn’t let it’s parent (= Router, Coordinator) know that it’s still there from time to time, the End Device will be thrown out of the PAN, and has to start joining all over again; which takes a relatively long time, which it doesn’t really have being powered down all the time..

Increasing the value for the Child Poll Timeout on the Coordinator (to a higher value then the minimum of 5 seconds) resolved everything.

On to the next ‘easy’ job; using the ATMega328 Watchdog Timer to put the RBBB to sleep 🙂

Testing Zigbee, Arduino and Domotica interface

This weekend i’ve been working on a setup to be able to test various things with the exciting Digi XBee modules that i’ve purchased some time ago.

XBee ZB modules and a RBBB

XBee ZB modules and a RBBB

As you can see there are 2 different types of XBee modules placed on the breadboard; there are 3 (a bit smaller) XBee Series 2 modules and 3 (larger) XBee-PRO modules. I also included an RBBB, a very small Arduino compatible device, that is located on the lower half of the board and is connected to the 6th XBee module. On the lower right side of the board there’s a 3.3V regulator to power the XBee modules.

First thing that had to be done was programming the upper row of 5 Digi XBee modules with the right firmware to let them all act as a End Device in AT/Transparent mode, and do some wiring. The XBee breakout board had already been soldered some time ago. I also added some LEDs for visualizing the status of the modules. After that, it was time do do some testing of my Domotica software to interface with these modules. Commands like “IS” for sampling the Digital/Analog IO ports on the modules. Here the first problem came up; the command did execute correctly cause i got a response back, but the payload of the frame was empty.. of course, after some time i realized i forgot to enable any of the I/O on the modules… 🙁

Next command on the list was the ZigBee Transmit Request Command. This command is used for sending data to a module where it will be sent to the UART. This way it will arrive at the device that is attached to the XBee, in my case the RBBB. This allows me to communicate with the Arduino wirelessly. All worked well, i got the right responses back and i saw data arriving on the RBBB.

Now it was time to start sending data from the RBBB to my Domotica system. Here the default sleep mode of the Zigbee took some time to resolve. The first sketch for the RBBB sent some text to the XBee every 15 seconds. But this only arrived on my PC once every 2 minutes or so… and i didn’t know why. Changing the sketch and now sending the same text every second, made the problem go away… Suddenly i realized is was the default sleep mode that was bugging me! The default sleep mode for an XBee with this firmware is “Cyclic Sleep”, which means the module is only awake periodically. Ofcourse, sending data to the UART of a sleeping XBee doesn’t work… I tried to change Sleep mode to 0 (“always awake”) but that’s not even supported! Hmm, fortunately there’s a workaround for this: set sleep mode to 1 (“Pin Hibernate”), ground Pin 9 (the yellow wire in the picture does that) and you’re done. While trying to change the sleep mode on a specific module the use of the LED really payed off, cause suddenly the LED for the wrong module went off.. it seemed i had addressed the wrong module with the Sleep mode set to Pin Hibernate command. Typically a case of where you can keep on searching for hours and hours why it’s not working as expected, and all you did wrong was addressing the wrong module…

Now i have a sketch running on the RBBB that transmits a small text every 10 seconds and it will echo anything that is received. This way i can start testing how reliable the combination of XBee and Arduino really is.

Working on Zigbee API mode interface

Since 4 weeks i have a Digi XStick. This is a USB module that provides connectivity to a XBee network:

XStick

XStick

This XStick ZB is configured to behave as a coordinator within a mesh topology. The XStick can be plugged directly into the USB port of a PC and doesn’t require batteries or power adapter since it’s USB powered. Last 2 weeks i’ve been working on a Zigbee interface for my domotica system, using ths XStick.

First some things you need to know..

An Xbee module has three communication modes:

  • Transparent mode,
  • Command mode
  • API mode.

At startup, an Xbee module is in transparent mode. In this mode, the module acts as a serial line replacement. All data received from the DIN pin is transmitted, and when RF data is being received, it is sent out on the DOUT pin. A pair of XBee modules can act as invisible cables in this mode.

Command mode is where you can change a large amount of settings of the XBee module. To enter Command mode you must send the characters “+++” and wait a second. Once the XBee enters command mode, it will answer with OK. Most of us will remember this behavior from modems. While in command mode you can change baud rate, destination address, etc etc. Leaving command mode can be accomplished by executing the ATCN command.

Sending messages to constantly changing targets (=other XBee modules), API mode is the best mode to choose. It is the most powerfull but also the most complicated mode to use. API (Application Programming Interface) mode is a frame-based method for sending and receiving data to and from an XBee.

API mode has some special abilities:

  • Changing parameters without entering command mode;
  • RSSI and source address information;
  • Receive packet delivery confirmation on every transmitted packet

Since API mode seems to be the most flexible, i decided to create an API-mode interface. With more then 140 pages of  information of how to interface with XBee/XBee-PRO ZB RF modules i knew this was a job that could take a while, but today i managed to get a sequence of API mode commands working.

The first command i started with  was the Node Discovery command, which will let every device on the network respond with basic information about that device. These reponses are received by the XStick, the address information of the responding XBee devices is stored and the next step is to send a request to all of the responding devices to request information about their hardware version. Today i succeeded in doing this first excercise, as you can see here:

Execute Node Discovery
Sending frame:7E 00 04 08 01 4E 44 64
Serialport.RxCount:33
RxBuffer:7E 00 1D 88 01 4E 44 00 86 23 00 13 A2 00 40 31 B9 04 45 44 41 54 32 00 00 00 02 00 C1 05 10 1E 12

*** Processing frame ***
ApiID = 88
Checksum Ok=True

ATCommandResponse, 29 bytes:
FrameID=1
Command=ND
Status=0
MY 8623
SH,SL 5526146518202628 (0013A2004031B904)
NI [EDAT2]
PARENT 00 00
DEVICE_TYPE 02
STATUS 00
PROFILE_ID C1 05
MANUFACTURER_ID 10 1E

Request Hardware Version for Node 8623
Sending frame:7E 00 0F 17 01 00 13 A2 00 40 31 B9 04 86 23 00 48 56 BD
Serialport.RxCount:21
RxBuffer:7E 00 11 97 01 00 13 A2 00 40 31 B9 04 86 23 48 56 00 19 44 E0

*** Processing frame ***
ApiID = 97
Checksum Ok=True

RemoteATCommandResponse, 17 bytes:
FrameID=1
Command=HV
Status=0
Response=19 44

So the XBee module that responded has a Hardware Version of 1944 🙂