XBee - API 2 bug

Wireless & IoT
1

Hi all,

I’ve been developing [libxbee for some time now.

I had previously written a piece of software that creates a pseudo terminal so that I can effectively multiplex communications between my PC and multiple endpoints (e.g: an arduino) through one XBee. It worked, though verification for avrdude failed (a lot), and I never investigated it because the write was always successful.

I’ve recently re-written this bit of software and included it with libxbee, and it works really well…

Unfortunately, running avrdude via this pseudo terminal still has issues with verification, and I decided to investigate it properly.

When running XBee modules in API mode 2, the module should escape the special bytes. It does to this, most of the time…

I have noticed some strange behavior, that I’ve detailed below. I am curious to know if anyone else has observed this.

At some point during the verify stage, the XBee will transmit a frame to the PC that is invalid.

Somewhere in the invalid frame there will be an ‘invalid’ escape sequence (it has escaped a value other than 0x7E, 0x7D, 0x11, and 0x13), and the checksum won’t validate. I’m fairly sure that I haven’t missed / hopped over a byte because there is no corruption in/before the next frame.

If I ignore the checksum and restore these invalid escaped bytes back to their original value, then avrdude will complete the verify, and then raise an issue stating something similar to:

avrdude: verification error, first mismatch at byte 0x1ab4
         0x11 != 0x31

This looks like software flow control has made it’s way through (XON/XOFF), but I don’t think it’s as simple as that (also, my XBee is configured for hardware flow control).

This behavior only seems to occur when the following conditions are met exactly:

  • During the verify step of avrdude - it is 95% recreatable when using a write/verify or just verify

  • Only with API frames that have a payload of either 41 or 111 bytes in length

If I switch to API mode 1, then everything is great and works (seemingly) 100% reliably.

I have also tried running at 9600 baud instead of my default of 57600. In this case it succeeds, very, very slowly.

I also remember reading somewhere that some XBees had a firmware bug, so I tried updating to the latest firmware (10ED).

I am using XBee Series 1.

An XBee Pro connected to a Sparkfun FTDI board to the PC.

An XBee (not Pro) connected to an Arduino FIO with the Arduino bootloader.

Has anyone experienced this? or got any info?

Thanks in advance! and apologies for the long post…](Google Code Archive - Long-term storage for Google Code Project Hosting.)

2

I thought I should include some debug output.

The ‘escaper’ is run on the data that each read() call returns, until the requested number of bytes has been read.

The interesting line is this:

39 / 41: 0x7D -{0xE0}-> 0xC0 nonsense

Which shows 0x7D (the escape byte) followed by 0xE0, with turns into 0xC0 after you xor it with 0x20.

This is not a byte that should be escaped, so for now I am turning it back into 0xE0

======= packet start (0x7E) =======
===== read length =====
-= escaper =-
  1 /  2: 0x00 --------> 0x00
  2 /  2: 0x29 --------> 0x29 ')'
-= escaper =- - -= lost 0 bytes =-
===== read payload =====
-= escaper =-
  1 / 41: 0x80 --------> 0x80
  2 / 41: 0x00 --------> 0x00
  3 / 41: 0x7D -{0x33}-> 0x13
  4 / 41: 0xA2 --------> 0xA2
  5 / 41: 0x00 --------> 0x00
  6 / 41: 0x40 --------> 0x40 '@'
  7 / 41: 0x3D --------> 0x3D '='
  8 / 41: 0xF0 --------> 0xF0
  9 / 41: 0x6F --------> 0x6F 'o'
 10 / 41: 0x3A --------> 0x3A ':'
 11 / 41: 0x00 --------> 0x00
 12 / 41: 0x0F --------> 0x0F
 13 / 41: 0xFF --------> 0xFF
 14 / 41: 0x1F --------> 0x1F
 15 / 41: 0xE8 --------> 0xE8
 16 / 41: 0x0F --------> 0x0F
 17 / 41: 0xF9 --------> 0xF9
 18 / 41: 0x1F --------> 0x1F
 19 / 41: 0xE1 --------> 0xE1
 20 / 41: 0x5C --------> 0x5C '\'
 21 / 41: 0xFE --------> 0xFE
 22 / 41: 0x4F --------> 0x4F 'O'
 23 / 41: 0xA0 --------> 0xA0
 24 / 41: 0x81 --------> 0x81
 25 / 41: 0xB1 --------> 0xB1
 26 / 41: 0x81 --------> 0x81
 27 / 41: 0xED --------> 0xED
 28 / 41: 0x01 --------> 0x01
 29 / 41: 0x92 --------> 0x92
 30 / 41: 0x81 --------> 0x81
 31 / 41: 0x8A --------> 0x8A
 32 / 41: 0x91 --------> 0x91
 33 / 41: 0x89 --------> 0x89
 34 / 41: 0x23 --------> 0x23 '#'
 35 / 41: 0x7D -{0x31}-> 0x11
 36 / 41: 0xF4 --------> 0xF4
 37 / 41: 0xDE --------> 0xDE
 38 / 41: 0x01 --------> 0x01
 39 / 41: 0x7D -{0xE0}-> 0xC0 nonsense
-= escaper =- - -= lost 3 bytes =-
-= escaper =-
 39 / 41: 0x31 --------> 0x31 '1'
 40 / 41: 0x97 --------> 0x97
 41 / 41: 0x10 --------> 0x10
-= escaper =- - -= lost 0 bytes =-
===== read checksum =====
-= escaper =-
  1 /  1: 0x37 --------> 0x37 '7'
-= escaper =- - -= lost 0 bytes =-
INVALID CHECKSUM... data loss has occured (packet length: 41)
3

I use the XBee API for 8 bit bytes, ASCII and binary, but I don’t use the mode where you must insert escape sequences. It’s much simpler to not do so.

4

Yeah… I have to admit I’m tempted to use API 1 instead. It even works properly!