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.

Alternatives to Cosm (Pachube)

There are a few alternatives to Cosm for handling devices that report over the web. I'm currently playing with Sen.se (open.sen.se) and it has some really cool features that I haven't seen before. See, I'm very interested in monitoring and controlling my house. I want to be able to tell if it's too hot, what the appliances are doing, is the darn garage door open, that kind of thing. I don't want to spend months learning how to create charts, pretty switches, or automatic backups for data stores. That's why services that connect devices on the web will someday be important. Someday, services like Sen.se and Cosm will be very important to the operation of devices. Anyway, Sen.se has a method of connecting to the data I'm already sending to Cosm. By adding a feed to my Cosm account I can use the Sen.se controls and displays to monitor my house. Cool, really cool. For example, here is a graph I put together in a few minutes using their tools (scroll down past it for more):

The chart will change based on the items I'm charting so you can see the latest data a minute or so after it gets posted on the Cosm site.  Additionally, it's interactive.  You can put your pointer over the control and see individual values and turn off parts of the chart.  There's also a problem putting more than one control on a blog page. They seem to interact with blogger and each other such that you can't get them to work together.  At least not yet (Sen.se is a beta site).

But isn't the chart cool?

Dogs and Rattlesnakes

After dealing with the second dog I've had bitten by a rattlesnake <link>, I decided people needed more information about snake avoidance.  There are a ton of sites out there that all espouse, what they say, is the right way to train a dog to avoid snakes.  There is a ton of misinformation and I just want to clear it up for people so they don't have the same problems I did.  There are a number of wrong things to do and a few right ones and I believe I have the experience now to tell the right from the wrong.  I've interviewed around twenty people who have used various trainers with varying results, and although they didn't realize they were being interviewed, they pointed out the various shortcomings.  Frankly, it's best to get the assistance of a professional snake trainer.  Very few people keep poisonous snakes around the house to be used for training dogs.  I'll start off with a few items that are very important.

When you arrive at the trainer, the cages for the snakes should already be set up.  The trainer should have done this before you got there; if they are not set up, leave and come back after they are.  The reason for this is the dog will see the cages being set up and associate any training to the cage, not the snakes inside.

The snakes MUST be alive and active.  A dead snake smells wrong and doesn't move around.  There's no point at all teaching your dog to avoid a dead snake. You want the dog to see the snake moving, hear its rattle, and realize this is another animal.

The trainer should have an empty cage for the dog to inspect.  This assures the dog that the cages are harmless.

The dog owner should be the one to walk the dog and participate in the training.  There are a couple of reasons for this.  The most important being that the owner knows how the dog will behave when it encounters a snake.  Each dog will behave a little differently from yelping and running away to just carefully skirting the snake.  You want to know the behavior in case of an encounter while on a walk through the woods.

The trainer should use a radio controlled shock collar.  Some people condemn this kind of tool as inhumane. Frankly, they are being silly.  You would MUCH rather your dog get a harmless shock than a snake bite.  Other methods, such as a water spray or loud noise just don't have the impact of a shock that isn't associated with a human in any way.  Besides, my dog loves getting sprayed with water.

So, a perfect session would consist of the trainer telling you what is going to happen and walking you through the steps first.  Then, you walk the dog over to the empty cage so it can be inspected and the dog gets familiar with the cages.  Then you walk by a cage with the snake in it.  The dog will get interested in the snake, go over, and inspect it.  When the trainer is assured that the dog has the scent, sight, and sound of the snake, the dog will get a shock.  Both you and the dog then run away from the snake to safety.  After a couple of  'good boys' you walk towards another cage with a snake or two in it.  The dogs reaction will vary a lot on the second cage.  Some dogs will want to go after the next snake, but most will shy away and not approach.  The last step is to allow the dog to wander freely (no leash) as you walk by the snake cages.  Your animal should not approach the snakes and may even warn you to stay away.

You see what is happening.  The dogs inherent curiosity will cause it to go to the snake and sniff around, the shock will tell it that this thing hurts, and running away will show the dog that it's OK to get away from harm. The empty cage will make sure the cage isn't a factor in the training; your dog will not be afraid of cages.  The live snake moves around, rattles, and probably will strike the side of the cage during the session.  You have safely exposed your pet to a dangerous situation and taught it how to respond.

The trainer should offer a second session a few weeks after the first to assure both you and the dog that the training has taken hold.  Personally, I like to take the dog back yearly to walk by the cages to be sure the little guy remembers those things are bad, and refresh my memory of the dog's behavior in this situation.

There are trainers that insist that dead snakes work just as well.  This simply isn't true.  You'll have a dog carefully trained to avoid dead snakes; not very useful.  There are other trainers that insist that they walk your dog through the course.  Their reasoning for this is the timing of the shock correction.  If it is given at the wrong time, you may not get the best results.  While this is true, it's really easy to tell the proper time for the correction.  Simply wait until the dog's entire attention is on the snake.  All of us with dogs know when that point happens; we've pulled our dog out of enough gopher holes to be quite familiar with it.  A snake trainer can easily tell while they are standing at the side watching us walk our dog up to the snake cage.  Special measures should be taken to keep the dog from associating the cage with the correction.  That's why an empty cage is a good idea at the start of the training course.

The first dog I had bitten by a snake was a loving little silky terrier.  He just wanted to play and was bitten on the side of his head.  Even though I got him to the vet within thirty minutes, he died.  I've had every dog since snake trained to protect them as much as possible from this particular danger.  The second dog that was bitten is detailed on the previous entry of this blog.  This little guy was just too young for the training and unlucky.  However, he not only survived the bite, he is totally recovered, and had his first training session just this morning.  In both cases, the vet bills were quite high; many, many times the cost of the training.

Several times now I have been with a trained dog when we encountered a rattlesnake in the wild.  In all cases, the dog alerted me to the danger before there was a possibility of a bite.  Think of snake training as a way of teaching the dog to warn you of danger when out for a walk or a run.  This means that a snake trained dog can warn children of danger when it's outside playing with them.  It certainly beats sit, roll over and beg for utility and usefulness and makes the cost of training sound worthwhile doesn't it?

This is the best training a person can give their pet if they live where such an encounter is possible.  If you live in Manhattan or the center of LA, it may not be necessary, but if you live in the suburbs skirting farm country or take your dog camping, consider doing this to protect your pet.

I love the desert, but....

Look at the picture below:

See the rattlesnake?  Here's a closer look:

If you look closely enough, you'll see the holes in its head from the 22 caliber snake shot rounds that killed it. This snake was hiding up against the side of my house inside the yard.  I discovered it when I went to pick up a toy my Irish Terrier puppy had left when he ran around the house.  It was dark and the snake's natural camouflage made it nearly invisible.  It didn't rattle until I actually almost stepped on it in the dark.

Yes, it did strike my dog.  The little guy was huddled up against the door into the house suffering from shock.  I grabbed the dog and headed straight for an emergency Vet's office.  

In answer to all comments about snake training, snake vaccines, watching my dog closely, keep it on a leash, etc.  The little guy is a little less than four months old.  The youngest the snake trainers will take him is 4 months and I already had an appointment for later this month.  The snake vaccine is usually given in February so it will be strongest in the spring when the snakes come out.  He was inside a fenced yard playing around my patio.  Crap like this sometimes happens no matter how many precautions you take.  And, yes, I often carry a handgun to handle situations like this, but neither I nor the puppy saw the snake in time to prevent the strike.  The handgun made short work of any possibility of this snake causing any further problems.

This is a picture of the little dog when he first came to live with me:

And here he is a couple of days ago, watching me fill his food bowl:

Fortunately, I've been overfeeding him and have gotten his weight up to almost 15 pounds so there was some body mass there to help with the snake venom.  He goes on a couple of half to three-quarter mile walks almost daily to build up some muscle and bone strength so he was very healthy.  And, he has every vaccination known to veterinary science, except snake, so opportunistic canine diseases are unlikely.

Barkley (his name) has been in the vet hospital now for over twelve hours, received lots of fluids, some narcotic pain killer, and two (and counting) vials of antivenin.  He's mostly out of shock and doing well considering the circumstances.  I'm going to go visit him in a few minutes because they are scheduled to do blood work on him soon to see how he's doing.  I want the results first hand.

So, you folks that have an aversion to handguns and people that carry them, think about this a while and what you would have done if it had been your dog.

Or child.

Update Oct 1, 2012 9:30PM:  Barkley can't come home tonight because his clotting factors are not good enough.  He'll have to stay tonight and may be able to come home tomorrow.  He's mostly alert and wants attention so I spent about a half hour in the floor with him hooked to an IV to let him know I was still around and hadn't abandoned him.  Last night when I left him, his head looked a lot like a bowling ball from the swelling; that has reduced a lot and he's eating.  I got another patient's person to take a picture of the little guy:

The red bandage is to protect his IV and the cone is because he kept trying to chew it.  They call it a 'No Cone' because they get tired of telling them 'NO' when they start chewing at the equipment.  He's eating and recognized me the minute I walked in the door.  Looks good for the little guy.

I'm going to get a flashlight now and wander around the house to see if there are any more snakes hanging around.

Update 2 October, 2012 12:25AM:  Got a call from the vet and Barkley's clotting factor improved and he said I could come get him.  The little guy is home running around chewing on a rawhide bone.  When I went to pick him up, he literally ran over to me.  This was far, far different from the little puppy in shock from a rattlesnake bite that I took to the hospital Sunday night. I may post a picture of him with the remaining swelling, but first Barkley and I are going to bed.

Don't ever say anything bad about an emergency veterinarian.

Update:  I put together a blog post about snake avoidance training <link>, do this if you have any worries at all about your dog.  If you take long walks in the wilderness or take it camping with you, it would be a really good idea.