Battery Charging - Part 5 (Harbor Freight item 42292)

Yes, I finally assembled and tested the various ideas into a single box for my float charger for lead acid batteries.  This project has been going on for over a year now and may be getting close to having a nice working prototype.  I incorporated a voltage display and an XBee set up to transmit analog readings into the mix.  So, what happens is you plug the charger into the wall and the XBee comes on, samples the voltage before the output diode and sends it to whatever device you set it up to talk to.  This way I can monitor the battery state of charge remotely without even having to go into the garage.  Here's an interior view of the charger:

On the lower left is the charging circuit that I came up with based (roughly) on the Harbor Freight 42292; at the top, stuck to the side is a series 2 XBee plugged into a breakout board; and on the right is the voltmeter display.  This is all enclosed in a plastic rectangular enclosure.  When assembled it looks like this:

Of course, since the XBee is a 3.3V device, I had to add a power supply for it.  I took the power directly from the float voltage and used an AP1117T33 regulator.  When I first started testing the combination, it got pretty hot pretty quickly, even when it wasn't hooked to a battery.  A little checking (I unplugged the XBee) told me that the XBee and its two LEDs were sucking enough power to heat it up, so I enabled sleep on the XBee.  This way, it would be off most of the time and only turn on to take a couple of measurements and transmit them.  This totally solved the problem.Here's the schematic I eventually settled on.  

If you're following this, you'll see that it's a simple variable supply that I set to 13.4V with resistor R2 which feeds a 3.3V supply to power the XBee.  The voltage divider R4, R5 sets the level that is in the 1.2V analog input range of the XBee.  Since these regulators sometimes tend to oscillate, I added capacitors C1 and C2 just to make sure I didn't drive the XBee nuts.  That's also why I added the resistor R6, to keep it away from reset.

To set it up, I put a 1K resistor across the output and set the voltage using R2 to 13.4 volts.  Then I centered the pot R5 and checked what was being transmitted.  By adjusting the pot, I was able to get a nice reading at the receiving end which I translated back into voltage and can display with an XBee connected Arduino.

There's a little jitter in the XBee readings caused by transients.  I can solve that two ways, add a capacitor on pin 20 of the XBee or do a rolling average on the receiving device.  I haven't decided which to do yet. I'm leaning toward a rolling average, but experience will tell me if it even needs to be fixed.  Here's a short sample of the Arduino output I set up.  Obviously, this isn't what I'll eventually use, but it's nice to be able to see the charger out in the garage:

A fun item I noticed is that the circuitry for monitoring the battery and transmitting the value can be separated from the charger.  That way I could hook a device to the battery and it would transmit the voltage to something that could alert me to go attend to the darn thing.  I may pursue that for something in the future.

No, I'm still not done.  This thing was a real pain to build.  It came up from several prototypes and kept getting more complex and looks like a mess because of this.  I think I may journey into getting a custom PC board made to put the thing together with since I want at least five of them.  Also, since I now have a box that will hold it, I'm going to mount the components on the lid with a wire to the display on the box part.  That way I can actually screw stuff down so it doesn't bounce around over time.

Apple Device: "Charging is not supported with this accessory"

I don't have a single Apple device in my house, no iPad, iPhone, iPod, iAnything.  I don't even have any apples.  However, the little wall warts I bought <link> have a bad reputation because they don't work on some iDevices.  While it's true that they don't, it really isn't their fault, it's Apple's.  This is the message:

Notice that it doesn't say that the device is the wrong voltage, wrong polarity, or wrong anything else?  That's because the device just doesn't meet the Apple standards of being made by Apple specifically for a particular Apple device.  They really, really want to lock you into buying your stuff from them and them alone.

My little chargers are fine and will work with Apple stuff with a simple modification that I won't do since I don't need to charge Apple devices.  What Apple did was use the D- and D+ (the two middle pins on a standard type A usb plug) to supply specific voltages that Apple could look at to tell if the charger was one of theirs.

Well, this little trick didn't last long before the engineers that make battery extenders and chargers figured it out.  Obviously, they grabbed a real apple charger and ripped it open to see what kind of shenanigans Apple was up to.  One manufacturer Lady Ada wrote up a nice description of what was happening and how she worked around it for one of her products, the MintyBoost.  She has a nice description of how she overcame the problem and made her stuff work <link>.

This also explains over 90% of the complaints on the web about various iDevices not working with a charger.  Basically, these two voltages (D1 and D2) are tiny and can vary a lot based on contact resistance, length of cable, net draw of the device, etc.  Basically any darn thing at all.  For example some of the solutions are to turn off the iPhone, plug the cable and charger into the phone, plug the charger into the wall, turn on the phone, repeat a number of times to allow the gremlins to align correctly.  And, this occasionally works.  Another solution is to lower the screen intensity, put the phone in airplane mode, then hook up the charger. There's always someone that says you need a new cable, better charger, or hold your mouth differently.  In the case of the iPhone, there was an OS update that caused a significant number people to have charging problems.  The fix for many of these non-technical folk was to go to the Apple store and get a new device or have a new part installed that will work.  Of course there are the Apple cultist that insist that only a new Apple charger will solve the problem.

But people, electrons are electrons and it isn't you or your device when a problem like this turns up, it's Apple exercising their control over their cult.  Annoying.

Don't despair yet.  There are ways to get around this problem that actually make sense.  No, you don't need to wet a Qtip with perfume and clean the contacts, letting it air dry for an hour(this is a real suggestion), there are much more mundane solutions.  For example, this site <link> talks about a little connector that has Apple plugs on both ends and works around the problem.  However, the darn thing is too expensive (I'm not a fan of this solution, but some of you might be).  There are several other similar devices out there that solve the problem.  You can also solve the problem by building something yourself (gasp !); I know this goes against life philosophy of the myriad teenagers that talked their parents into getting this cool new gadget, but life isn't fair.

Just cut a USB charging cable that mates with the device and add a little voltage divider.  The schematic of the changes is:

If this picture doesn't look familiar, take another look at Lady Ada's description, it was taken directly from there.  See, Apple uses the voltage divider to set specific voltages on D+ and D- to identify their devices.  Other manufacturers don't do this kind of thing unless they're trying to meet the USB charging standards, and for a low price device it isn't worth the effort or cost. Just another effort of Apple to wrangle you into their pen.

So, you ask, "What do you care, you don't own an Apple device?"  I don't, but my less fortunate friends, neighbors, and relatives do.  They get really annoyed when their devices won't work on one of my chargers when they come to visit, and they hate it when a charger stops working and gives them this silly, non descriptive message.  Also, I found zero, nada, explanations of what was going on to help people with this problem.  That annoyed me more than anything else, so I decided to post it here and a couple of other places, hoping that poor souls that are eating up Google cpu cycles could, at least, understand the problem better.

Soak a Qtip in perfume and clean the contacts?  Really?

Tiny Power Supplies for Micro Controller Projects

When you build micro controller projects, eventually you want to do something real that will have to work long term.  For this you need a power supply that is small, maybe small enough to put in a light switch, ceiling fan, or dryer control panel.  These things are hard to find.  I've spent hours on Google trying to find really small 5V supplies with some success, but never fitting my needs.  Nice little supplies that you have to buy in 100+ quantities, nice little supplies that cost US $50, etc are out there, but who wants to invest that kind of money in a technology that changes almost daily?

In a few project postings I describe how I cut the guts out of a wall wart like this:

These little devices work great as microcontroller power supplies.  The one above will put out up to 2A and doesn't seem to get hot doing it.  I've had several in service, out in the weather for two years.  At a cost less than US $5 each (usually with free shipping) they are a fine solution.  I've taken the supply out of the plastic case and installed it into devices like this <link>:

The little board in the upper left is the guts of the wall wart.  I've even used the entire wall wart as a mounting platform for another device:

This device <link> has an XBee mounted on the side of the wall wart transmitting temperature every minute or so.  All-in-all, a pretty useful device repurposed from the iPad craze.  However, technology moves on and I want to try a couple of ideas that would work better if I had an even smaller power supply.  I asked on a couple of forums and was pointed to one of these:

I already had two of them charging mobile devices in the house so I decided to gut one of them and see what was inside:

This little supply is TINY. Yes, I had to cut the case off with a Dremel to get to the guts; the top was seriously glued to the bottom and refused to come off. The two board with connecting cable configuration could create a problem mounting, but nothing I can't overcome, and the wires to the AC pins might give me a problem, but it couldn't be too hard to solve; I like this.  So, looking around the web to see what kind of deal I could get on them I found them for US $1 on Amazon.  Yes, you read that right, a single dollar, with free shipping.  So:

Here's my pile of stock devices.  

Since supply and demand act on everything, the price at Amazon has gone up to US $1.45 as of this writing and could go either up or down based on activity, but they are still a bargain.  

Even with this solution available, I'm still searching for possibilities.  The rough requirements for the supply are: minuscule size, 5V at a least an amp (relays, you know), easy to mount, things like that.  

To you suppliers out there, there's a market here that you aren't exploiting.  SparkFun, Lady Ada, Itead, etc. are you listening?  You folks in China, what are you waiting for?

Using the XBee Library Part 2

Previously, I talked about using Andrew Rapp's XBee library on a project and posted an example.  This is the second example I've been working on.  The objective is to understand the library well enough to re-implement some of my devices using the library because I'm getting tired of doing my own parsing of the basic packet.  Yes, I have finer control, but I've found I don't really need finer control.  So, here is an example of using the code on an Arduino 2560 with the XBee connected to Serial3.  This leaves me two unused serial ports to play with since I'm using the main serial port as my debugging and status port.

The Arduino Sketch

/*
XBee RX test for a Arduino Mega2560 using Serial3 as the XBee serial
input for a Series 2 XBee.  I took Andrew Rapp's receive example and modified
it heavily.

I wanted to experiment with and better understand how to use his XBee
library for an actual project.  With the inclusion of support for SoftwareSerial
so that the XBee can be put on digital pins leaving the Arduino serial port
available for debugging and status, the library's usefullness shot way up.  These
changes also allow for the use of the additional serial ports on a Mega2560

This is a HEAVILY commented example of how to grab a receive packet off the
air and do something with it using series 2 XBees.  This example also supports
a remote XBee end device sending analog data.  Series 1 XBees are left as an
exercise for the student.
*/

#include <XBee.h>

XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
// create reusable response objects for responses we expect to handle
ZBRxResponse rx = ZBRxResponse();
ZBRxIoSampleResponse ioSample = ZBRxIoSampleResponse();

void setup() {
  // start serial
  Serial.begin(9600);
  // and the third serial port
  Serial3.begin(9600);
  // now that they are started, hook the XBee into
  // the third serial port
  xbee.setSerial(Serial3);
  // I think this is the only line actually left over
  // from Andrew's original example
  Serial.println("starting up yo!");
}

void loop() {
    // doing the read without a timer makes it non-blocking, so
    // you can do other stuff in loop() as well.
    xbee.readPacket();
    // so the read above will set the available up to
    // work when you check it.
    if (xbee.getResponse().isAvailable()) {
      // got something
      // I commented out the printing of the entire frame, but
      // left the code in place in case you want to see it for
      // debugging or something.  The actual code is down below.
      //showFrameData();
      Serial.print("Frame Type is ");
      // Andrew calls the frame type ApiId, it's the first byte
      // of the frame specific data in the packet.
      Serial.println(xbee.getResponse().getApiId(), HEX);
   
      if (xbee.getResponse().getApiId() == ZB_RX_RESPONSE) {
        // got a zb rx packet, the kind this code is looking for
     
        // now that you know it's a receive packet
        // fill in the values
        xbee.getResponse().getZBRxResponse(rx);
     
        // this is how you get the 64 bit address out of
        // the incoming packet so you know which device
        // it came from
        Serial.print("Got an rx packet from: ");
        XBeeAddress64 senderLongAddress = rx.getRemoteAddress64();
        print32Bits(senderLongAddress.getMsb());
        Serial.print(" ");
        print32Bits(senderLongAddress.getLsb());
     
        // this is how to get the sender's
        // 16 bit address and show it
        uint16_t senderShortAddress = rx.getRemoteAddress16();
        Serial.print(" (");
        print16Bits(senderShortAddress);
        Serial.println(")");
     
        // The option byte is a bit field
        if (rx.getOption() & ZB_PACKET_ACKNOWLEDGED)
            // the sender got an ACK
          Serial.println("packet acknowledged");
        if (rx.getOption() & ZB_BROADCAST_PACKET)
          // This was a broadcast packet
          Serial.println("broadcast Packet");
       
        Serial.print("checksum is ");
        Serial.println(rx.getChecksum(), HEX);
     
        // this is the packet length
        Serial.print("packet length is ");
        Serial.print(rx.getPacketLength(), DEC);
     
        // this is the payload length, probably
        // what you actually want to use
        Serial.print(", data payload length is ");
        Serial.println(rx.getDataLength(),DEC);
     
        // this is the actual data you sent
        Serial.println("Received Data: ");
        for (int i = 0; i < rx.getDataLength(); i++) {
          print8Bits(rx.getData()[i]);
          Serial.print(' ');
        }
     
        // and an ascii representation for those of us
        // that send text through the XBee
        Serial.println();
        for (int i= 0; i < rx.getDataLength(); i++){
          Serial.write(' ');
          if (iscntrl(rx.getData()[i]))
            Serial.write(' ');
          else
            Serial.write(rx.getData()[i]);
          Serial.write(' ');
        }
        Serial.println();
        // So, for example, you could do something like this:
        handleXbeeRxMessage(rx.getData(), rx.getDataLength());
        Serial.println();
      }
      else if (xbee.getResponse().getApiId() == ZB_IO_SAMPLE_RESPONSE) {
        xbee.getResponse().getZBRxIoSampleResponse(ioSample);
        Serial.print("Received I/O Sample from: ");
        // this is how you get the 64 bit address out of
        // the incoming packet so you know which device
        // it came from
        XBeeAddress64 senderLongAddress = ioSample.getRemoteAddress64();
        print32Bits(senderLongAddress.getMsb());
        Serial.print(" ");
        print32Bits(senderLongAddress.getLsb());
     
        // this is how to get the sender's
        // 16 bit address and show it
        // However, end devices that have sleep enabled
        // will change this value each time they wake up.
        uint16_t senderShortAddress = ioSample.getRemoteAddress16();
        Serial.print(" (");
        print16Bits(senderShortAddress);
        Serial.println(")");
        // Now, we have to deal with the data pins on the
        // remote XBee
        if (ioSample.containsAnalog()) {
          Serial.println("Sample contains analog data");
          // the bitmask shows which XBee pins are returning
          // analog data (see XBee documentation for description)
            uint8_t bitmask = ioSample.getAnalogMask();
            for (uint8_t x = 0; x < 8; x++){
            if ((bitmask & (1 << x)) != 0){
              Serial.print("position ");
              Serial.print(x, DEC);
              Serial.print(" value: ");
              Serial.print(ioSample.getAnalog(x));
              Serial.println();
            }
          }
        }
        // Now, we'll deal with the digital pins
        if (ioSample.containsDigital()) {
          Serial.println("Sample contains digtal data");
          // this bitmask is longer (16 bits) and you have to
          // retrieve it as Msb, Lsb and assemble it to get the
          // relevant pins.
          uint16_t bitmask = ioSample.getDigitalMaskMsb();
          bitmask <<= 8;  //shift the Msb into the proper position
          // and in the Lsb to give a 16 bit mask of pins
          // (once again see the Digi documentation for definition
          bitmask |= ioSample.getDigitalMaskLsb();
          // this loop is just like the one above, but covers all
          // 16 bits of the digital mask word.  Remember though,
          // not all the positions correspond to a pin on the XBee
          for (uint8_t x = 0; x < 16; x++){
            if ((bitmask & (1 << x)) != 0){
              Serial.print("position ");
              Serial.print(x, DEC);
              Serial.print(" value: ");
              // isDigitalOn takes values from 0-15
              // and returns an On-Off (high-low).
              Serial.print(ioSample.isDigitalOn(x), DEC);
              Serial.println();
            }
          }
        }
        Serial.println();
      }

      else {
        Serial.print("Got frame id: ");
        Serial.println(xbee.getResponse().getApiId(), HEX);
      }
    }
    else if (xbee.getResponse().isError()) {
      // some kind of error happened, I put the stars in so
      // it could easily be found
      Serial.print("************************************* error code:");
      Serial.println(xbee.getResponse().getErrorCode(),DEC);
    }
    else {
      // I hate else statements that don't have some kind
      // ending.  This is where you handle other things
    }
}

void handleXbeeRxMessage(uint8_t *data, uint8_t length){
  // this is just a stub to show how to get the data,
  // and is where you put your code to do something with
  // it.
  for (int i = 0; i < length; i++){
//    Serial.print(data[i]);
  }
//  Serial.println();
}

void showFrameData(){
  Serial.println("Incoming frame data:");
  for (int i = 0; i < xbee.getResponse().getFrameDataLength(); i++) {
    print8Bits(xbee.getResponse().getFrameData()[i]);
    Serial.print(' ');
  }
  Serial.println();
  for (int i= 0; i < xbee.getResponse().getFrameDataLength(); i++){
    Serial.write(' ');
    if (iscntrl(xbee.getResponse().getFrameData()[i]))
      Serial.write(' ');
    else
      Serial.write(xbee.getResponse().getFrameData()[i]);
    Serial.write(' ');
  }
  Serial.println();
}

// these routines are just to print the data with
// leading zeros and allow formatting such that it
// will be easy to read.
void print32Bits(uint32_t dw){
  print16Bits(dw >> 16);
  print16Bits(dw & 0xFFFF);
}

void print16Bits(uint16_t w){
  print8Bits(w >> 8);
  print8Bits(w & 0x00FF);
}

void print8Bits(byte c){
  uint8_t nibble = (c >> 4);
  if (nibble <= 9)
    Serial.write(nibble + 0x30);
  else
    Serial.write(nibble + 0x37);
     
  nibble = (uint8_t) (c & 0x0F);
  if (nibble <= 9)
    Serial.write(nibble + 0x30);
  else
    Serial.write(nibble + 0x37);
}

It was actually pretty easy to convert my previous example to the 2560; I just changed the port in setSerial() to Serial3 instead of newsoftserial and it worked.  This left me a little time to play with capturing an I/O packet and taking it apart.  The code to handle an I/O packet is in this example.

I wanted the I/O packet because I have an XBee outside on a pole measuring the temperature that sends I/O packets periodically and I want to set up a battery monitor for my lead acid batteries to keep track of their state of charge.  You don't need an Arduino hooked to an XBee for these purposes, but you do need to be able to receive and decode the packets.

Once again, feel free to grab the code and modify it for your purposes.

Using the XBee library

Recently Paul Stoffregen created a new software serial library for the Arduino, then he modified Andrew Rapp's XBee library to use it (as well as the older, but really great, SoftwareSerial libray).  Suddenly, the XBee library is something that could be really useful.

See, the XBee library has traditionally been hooked into the hardware serial lines on Arduino Pins 0 and 1.  That means getting debugging information out of the device combination of an Arduino and an XBee is an exercise in frustration and annoyance.  Sure, you can use blinking lights to tell you what is going on, but this is the 21st century.  I have always written my own code to handle the XBee interaction because I wanted the serial port to provide status and control when I was working on a project.  Additionally, Andrew's library is heavily c++ and all the classes, inheritance, and instances confused the heck out of me.

However, maybe with the inclusion of a modified software serial port, and the capability to use the additional ports on an Arduino Mega, now is the time to take a serious look at using it.  I mean, if you have a mega, you can now put the XBee on Serial1 and keep Serial and Serial 2 for other things; this is just the ticket for converting RS485 into XBee packets to send over the air where you don't have wires.  Heck, I can think of dozens of things.

So, here is my first voyage into the use of the library.  I haven't linked in Paul's new serial library yet, I will on a future example, but I just wanted to understand what was going on and how to, at least, receive a packet and do something with it.  I took one of Andrew's library examples and modified it substantially to include many of the things I need in using an XBee and commented the heck out of it so others stood a chance of understanding what was going on.  It's amazing how few examples are out there that actually show what you need to do to do something along these lines.

The Arduino Sketch

/**
I took Andrew Rapp's receive example and modified it to be completely
unrecognizable.

I wanted to experiment with and better understand how to use his XBee
library for an actual project.  With the inclusion of support for SoftwareSerial
so that the XBee can be put on digital pins leaving the Arduino serial port
available for debugging and status, the library's usefullness shot way up.

This is a HEAVILY commented example of how to grab a receive packet off the
air and do something with it using series 2 XBees.  Series 1 XBees are left as
and exercise for the student.
*/

#include <XBee.h>
#include <SoftwareSerial.h>

XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
// create reusable response objects for responses we expect to handle
ZBRxResponse rx = ZBRxResponse();

// Define NewSoftSerial TX/RX pins
// Connect Arduino pin 2 to Tx and 3 to Rx of the XBee
// I know this sounds backwards, but remember that output
// from the Arduino is input to the Xbee
#define ssRX 2
#define ssTX 3
SoftwareSerial nss(ssRX, ssTX);


void setup() {
  // start serial
  Serial.begin(9600);
  // and the software serial port
  nss.begin(9600);
  // now that they are started, hook the XBee into
  // Software Serial
  xbee.setSerial(nss);
  // I think this is the only line actually left over
  // from Andrew's original example
  Serial.println("starting up yo!");
}

void loop() {
    // doing the read without a timer makes it non-blocking, so
    // you can do other stuff in loop() as well.
    xbee.readPacket();
    // so the read above will set the available up to
    // work when you check it.
    if (xbee.getResponse().isAvailable()) {
      // got something
      Serial.println();
      Serial.print("Frame Type is ");
      // Andrew call the frame type ApiId, it's the first byte
      // of the frame specific data in the packet.
      Serial.println(xbee.getResponse().getApiId(), HEX);
   
      if (xbee.getResponse().getApiId() == ZB_RX_RESPONSE) {
        // got a zb rx packet, the kind this code is looking for
     
        // now that you know it's a receive packet
        // fill in the values
        xbee.getResponse().getZBRxResponse(rx);
     
        // this is how you get the 64 bit address out of
        // the incoming packet so you know which device
        // it came from
        Serial.print("Got an rx packet from: ");
        XBeeAddress64 senderLongAddress = rx.getRemoteAddress64();
        print32Bits(senderLongAddress.getMsb());
        Serial.print(" ");
        print32Bits(senderLongAddress.getLsb());
     
        // this is how to get the sender's
        // 16 bit address and show it
        uint16_t senderShortAddress = rx.getRemoteAddress16();
        Serial.print(" (");
        print16Bits(senderShortAddress);
        Serial.println(")");
     
        // The option byte is a bit field
        if (rx.getOption() & ZB_PACKET_ACKNOWLEDGED)
            // the sender got an ACK
          Serial.println("packet acknowledged");
        if (rx.getOption() & ZB_BROADCAST_PACKET)
          // This was a broadcast packet
          Serial.println("broadcast Packet");
       
        Serial.print("checksum is ");
        Serial.println(rx.getChecksum(), HEX);
     
        // this is the packet length
        Serial.print("packet length is ");
        Serial.print(rx.getPacketLength(), DEC);
     
        // this is the payload length, probably
        // what you actually want to use
        Serial.print(", data payload length is ");
        Serial.println(rx.getDataLength(),DEC);
     
        // this is the actual data you sent
        Serial.println("Received Data: ");
        for (int i = 0; i < rx.getDataLength(); i++) {
          print8Bits(rx.getData()[i]);
          Serial.print(' ');
        }
     
        // and an ascii representation for those of us
        // that send text through the XBee
        Serial.println();
        for (int i= 0; i < rx.getDataLength(); i++){
          Serial.write(' ');
          if (iscntrl(rx.getData()[i]))
            Serial.write(' ');
          else
            Serial.write(rx.getData()[i]);
          Serial.write(' ');
        }
        Serial.println();
     
        // So, for example, you could do something like this:
        handleXbeeRxMessage(rx.getData(), rx.getDataLength());
/*
        // I commented out the printing of the entire frame, but
        // left the code in place in case you want to see it for
        // debugging or something
        Serial.println("frame data:");
        for (int i = 0; i < xbee.getResponse().getFrameDataLength(); i++) {
          print8Bits(xbee.getResponse().getFrameData()[i]);
          Serial.print(' ');
        }
        Serial.println();
        for (int i= 0; i < xbee.getResponse().getFrameDataLength(); i++){
          Serial.write(' ');
          if (iscntrl(xbee.getResponse().getFrameData()[i]))
            Serial.write(' ');
          else
            Serial.write(xbee.getResponse().getFrameData()[i]);
          Serial.write(' ');
        }
        Serial.println();
*/
      }
    }
    else if (xbee.getResponse().isError()) {
      // some kind of error happened, I put the stars in so
      // it could easily be found
      Serial.print("************************************* error code:");
      Serial.println(xbee.getResponse().getErrorCode(),DEC);
    }
    else {
      // I hate else statements that don't have some kind
      // ending.  This is where you handle other things
    }
}

void handleXbeeRxMessage(uint8_t *data, uint8_t length){
  // this is just a stub to show how to get the data,
  // and is where you put your code to do something with
  // it.
  for (int i = 0; i < length; i++){
//    Serial.print(data[i]);
  }
//  Serial.println();
}

// these routines are just to print the data with
// leading zeros and allow formatting such that it
// will be easy to read.
void print32Bits(uint32_t dw){
  print16Bits(dw >> 16);
  print16Bits(dw & 0xFFFF);
}

void print16Bits(uint16_t w){
  print8Bits(w >> 8);
  print8Bits(w & 0x00FF);
}

void print8Bits(byte c){
  uint8_t nibble = (c >> 4);
  if (nibble <= 9)
    Serial.write(nibble + 0x30);
  else
    Serial.write(nibble + 0x37);
     
  nibble = (uint8_t) (c & 0x0F);
  if (nibble <= 9)
    Serial.write(nibble + 0x30);
  else
    Serial.write(nibble + 0x37);
}

I tried to get all the major items out of the packet so they could be displayed and even included a tiny routine to illustrate using the received data.  This is what it looks like running:

You have to use the scrollbar at the bottom to see all of the message, but I wanted it that way instead of worrying about wrapping around.  I also put in print routines for the hex data; I love being able to see it in both hex and ascii.

Grab it, modify it to your purpose, and have fun.

Monitoring My XBee Network

In the previous post <link> I wrote about how I discovered broadcast mode can cause problems as you increase the number of nodes.  That led to a method of monitoring each node to see what it was actually doing, and by watching each of them in turn, seeing how the traffic patterns work out.

Well, I left it kind of up-in-the-air on exactly how I did it.  Basically, I used the examples that Akiba of Freaklabs released for various functions and created a sniffer of sorts.  This is necessary because the XBee only sends out the serial port data intended for the particular radio module you're plugged into.  That's what makes broadcast mode so useful, you can see all the traffic and chase problems.  With a Freakduino Chibi board, you can monitor all the devices on your network at once, but that is way too much information to try to wade through.  By setting the Chibi board to promiscuous mode and then writing code to filter by address, you can watch any node in the network to see what is going on with that particular device.  This makes it possible to see its traffic even though you aren't using an XBee.

Here's the code I came up with:

The Arduino Sketch

/*
This sketch enables promiscuous mode on the Freakduino boards and then
filters by device address to watch a particular node.

I had to change the buffer size in the chibi library for promiscuous mode
because, being set to 1024 with another buffer for the packet to be manipulated
caused the board to run out of RAM.  Just go into the chibi library and
find the receive buffer in chb_buf.h and set it to what you want.  I used the
value 500, and it seems to work fine

Before using this sketch, also go into the chibiUsrCfg.h file and
enable promiscuous mode. To do this, change the definition:

#define CHIBI_PROMISCUOUS 0
to
#define CHIBI_PROMISCUOUS 1

When not using promiscuous mode, disable this setting by changing
it back to 0.
*/

#include <chibi.h>
#include <avr/pgmspace.h>
#include <MemoryFree.h>

/*
Addresses of devices in my network
                    Long     Short
Garage Controller 407A 38AF  A019
Power Monitor     4031 566B  CD6B
Controller        4055 B0A6  97FA
Status Display    406F B6B5  9BE8
Pool Controller   4079 B2BD  9370
Temp1             406F 7FAC  1B1E
House Clock       4055 B094  0
Acid Pump         406F B7AF  7D58
*/
char *deviceName[] = {"Garage Controller",
                       "Power Monitor",
                       "Controller",
                       "Status Display",
                       "Pool Controller",
                       "Temp1",
                       "House Clock",
                       "Acid Pump"};
uint16_t deviceAddress[] = {0xA019,
                         0xCD6B,
                         0x97FA,
                         0x9BE8,
                         0x9370,
                         0x1B1E,
                         0x0,
                         0x7D58};
uint16_t listenTo;
byte Pbuf[500];
char Dbuf[50];
int longest = 0;

void showMem(){
  strcpy_P(Dbuf,PSTR("Mem = "));
  Serial.print(Dbuf);
  Serial.println(freeMemory());
}

/**************************************************************************/
// Initialize
/**************************************************************************/
void setup()
{
  // Init the chibi stack
  Serial.begin(115200);
  chibiInit();
  strcpy_P(Dbuf,PSTR("\n\r***************I'm alive**************"));
  Serial.println(Dbuf);
  unsigned int choice = 0;
  Serial.println("Pick a device to listen to");
  for(int i = 0; i < sizeof(deviceName)/sizeof(deviceName[0]); i++){
    Serial.print((char)(i + 'A'));
    Serial.print(" - ");
    Serial.println(deviceName[i]);
  }
  Serial.print("> ");
  // this only accepts a single character for the device choice.
  // that's because the chibi board runs at 8MHz on the internal clock and
  // internal clocks aren't accurate.  This means the higher baud rates sometimes
  // have problems.  When I worked on this I couldn't get the board to accept more
  // than one character correctly at baud rates over 57K.  Works fine at 9600,
  // but I want to output the data far faster than that.
  while(1){
    if(Serial.available() != 0){
      char c = Serial.read();
      Serial.write(c);
      Serial.println();
      choice = toupper(c) - 'A';
      if (choice < sizeof(deviceName)/sizeof(deviceName[0]))
        break;
      else {
        Serial.println(" oops, try again");
        Serial.print("> ");
      }
    }
  }
  listenTo = deviceAddress[choice];
  strcpy_P(Dbuf,PSTR("Starting Radio, Result = "));
  Serial.print(Dbuf);
  Serial.println(chibiSetChannel(12),DEC);
  strcpy_P(Dbuf,PSTR("Listening to "));
  Serial.print(Dbuf);
  Serial.print(deviceName[choice]);
  strcpy_P(Dbuf,PSTR(" at address "));
  Serial.print(Dbuf);
  Serial.println(listenTo, HEX);
  showMem();
}

/**************************************************************************/
// Loop
/**************************************************************************/
void loop()
{
  // Check if any data was received from the radio. If so, then handle it.
  if (chibiDataRcvd() == true)
  {
    int len;
    uint16_t senderAddress;
 
    // send the raw data out the serial port in binary format
    len = chibiGetData(Pbuf);
    if (len > longest)
      longest = len;
    senderAddress = chibiGetSrcAddr();
    if (senderAddress == listenTo && len > 0){
      strcpy_P(Dbuf,PSTR("From: "));
      Serial.print(Dbuf);
      Serial.print(senderAddress,HEX);
      strcpy_P(Dbuf,PSTR(" Len: "));
      Serial.print(Dbuf);
      Serial.print(len);
      strcpy_P(Dbuf,PSTR(" Longest: "));
      Serial.print(Dbuf);
      Serial.println(longest);
      for (int i= 0; i < len; i++){
        uint8_t nibble = (uint8_t) (Pbuf[i] >> 4);
        if (nibble <= 9)
          Serial.write(nibble + 0x30);
        else
          Serial.write(nibble + 0x37);
     
        nibble = (uint8_t) (Pbuf[i] & 0x0F);
        if (nibble <= 9)
          Serial.write(nibble + 0x30);
        else
          Serial.write(nibble + 0x37);
        Serial.print(' ');
      }
      Serial.println();
      for (int i= 0; i < len; i++){
        uint8_t nibble = (uint8_t) (Pbuf[i] >> 4);
        Serial.write(' ');
        if (iscntrl(Pbuf[i]))
          Serial.write(' ');
        else
          Serial.write(Pbuf[i]);
        Serial.write(' ');
      }
      Serial.println();
    }
  }
}

A couple of things to keep in mind.  The Chibi board is only running at 8 Mhz, so it can't keep up with unlimited traffic flying through the air at 250Kb forever.  If you spend too much time in the code checking and decoding, you'll miss packets.  The Chibi library sets a buffer size of 1024 to handle packets being received to help with this, but you'll have to reduce this size because the MCU only has 2K of ram to begin with.  I point this out in the code.  The maximum size of a packet is 127 bytes, so make your parsing buffer longer than that.  I print the maximum packet length in the code above, and have never seen a packet larger, so it appears the library is working fine for separating the packets.  I also put a routine in the code to monitor  memory usage.  Use this to keep track so you don't run out with the various buffers and such.

Here's a sample of the output using the serial monitor from the Arduino IDE:

It doesn't wrap around, but that could be easily added.  I just use the scroll bar on the bottom to move around.  I output the hex values as well as the ascii so I can recognize the various packets as well as decode the binary portions of the data.

So, as your network grows, or you have problems right off the bat, consider this combination of things as a possible tool to help you get past it.  Of course, you're welcome to grab the code and modify it to your particular network and need for monitoring.

More About XBee Broadcast

I discuss the usefulness of XBee broadcast here <link>, but there is a problem with this I didn't foresee.  It seems that, if you get enough devices, the network gets flooded and becomes unreliable.  You see, the beauty of XBees is that they implement mesh protocol such that you can have a message forwarded from XBee to XBee until it reaches its destination many hops away.  This is a really good thing because an XBee at the far end of the house can communicate with another one at the opposite end.

I tested this several times by separating a couple of XBees to where they couldn't communicate, then completed the circuit by simply placing one in the middle to forward the data.  This means I can go from my barn to my controller with a message without worrying about how far it is, or getting a high power version of the XBee.

The problem comes when a broadcast is transmitted by a device far away and is echoed by several of them to assure it gets to its destination.  The Zigbee packet gets a little larger with each hop since it carries the routing information along with it and eventually, the channel is flooded with messages bouncing around.

Introducing the Freakduino Chibi.

I found this when I bought a new device to take a look at the network.  This little device <link>  is an IEEE 802.15.4 radio mounted with an Arduino compatible MCU.   The little device can be programmed to listen in promiscuous mode such that it hears all the packets in range, and at my house this means almost all the devices can be monitored.  There's also the possibility of hooking this into WireShark, but I couldn't get that to work reliably.  What I did was simply set up a small program that will listen to any of my devices individually to see what traffic is passing through it and just sat back and observed what was going on one device at a time.

The Acid Pump would send a broadcast that was echoed by several devices trying to forward the message to some other device effectively more than doubling the traffic for each device.  When they were all doing things, the channel was flooded with superfluous repeated messages such that collisions were constantly happening.  There just wasn't enough dead air time for any of them to transmit.  I lost messages because they overlapped each other and checksums were bad because the devices overlapped at times.

I'm still a big fan of broadcast, it definitely has its place.  For example, a new device that you want to carefully monitor for a few days to be sure you got the set up correct, or a device that is having some problems and needs to be monitored.  However, don't go nuts with it like I did. So, what you can do is set your code up to transmit in broadcast initially to get the bugs out then change it to a specific address when you're comfortable that it is working correctly.  Then get a Freakduino Chibi to check it from time to time or when you suspect something might be wrong with it

As you can see, it is a little bigger than an Arduino, but that's OK since it has an optional enclosure that houses it nicely:

This is the combination I bought.  Then, I took his example code, modified the heck out of it such that it could watch a particular device (even if the device was transmitting to a specific address) and was able to troubleshoot my network.  

Of course it isn't perfect.  The Freakduino only runs at 8MHz, so it's entirely possible for it to be unable to keep up with the traffic on a heavily loaded network like mine used to be, and there are probably a couple of problems with the library he provides to get you going, but that's the kind of thing we're best at.

So, I was able to cut the traffic down on my network by a huge amount, and I can monitor any device to see what is actually happening.  Now, I have bandwidth to add even more devices.