0x90 Data Frame Weirdness

XBee & XBee Gateway XBee - 802.15.4
1

Hello,

I’m sending a 0x10 Transmit Request frame from my PC through a coordinator in API mode (with escape characters, AP=2), to an XBee configured as a router, also in API mode with AP=2, hooked up to an Arduino. I’m sending a frame that specifies a length of 15, with one byte of payload data thusly:

buf[ 0] = 0x7E; // Start byte
buf[ 1] = 0x00; // High byte of message length
buf[ 2] = 15; // Low byte of message length
buf[ 3] = 0x10; // Frame type: transmit request
buf[ 4] = 0x00; // Frame ID: set to 0 for no reply
buf[ 5] = (XBSH & 0xFF000000) >> 24; // MSB of XBee target 64-bit address
buf[ 6] = (XBSH & 0x00FF0000) >> 16;
buf[ 7] = (XBSH & 0x0000FF00) >> 8;
buf[ 8] = (XBSH & 0x000000FF);
buf[ 9] = (XBSL & 0xFF000000) >> 24;
buf[10] = (XBSL & 0x00FF0000) >> 16;
buf[11] = (XBSL & 0x0000FF00) >> 8;
buf[12] = (XBSL & 0x000000FF); // LSB of target 64-bit address
buf[13] = 0xff; // MSB: XBee target 16-bit address
buf[14] = 0xfe; // LSB: Xbee target 16-bit address
buf[15] = 0x00; // Broadcast radius (set to 0 for max hops)
buf[16] = 0x00; // Transmission options (none)
buf[17] = 0x34; // Payload
cksum = 0;
for(i=3; i<18; i++)
cksum += buf[i];
buf[18] = 0xFF - (cksum & 0xFF);
write(fd, buf, 19);

The receiving Xbee gets a 0x90 Receive Packet, however the length is 13 and the bytes received are:

buf[0] = 0x7E correct, start delimiter
buf[1] = 0x00 correct, msb of length
buf[2] = 0x0D lsb of length = 13
buf[ 3] = 0x90 correct, frame type
buf[ 4] = 0x00 correct, frame ID
buf[ 5] = 0x7D huh? Shouldn’t this be 0x13?
buf[ 6] = 0x33 Shouldn’t this be 0xA2?
buf[ 7] = 0xA2 Umm… everything is offset a byte now
buf[ 8] = 0x00
buf[ 9] = 0x40
buf[10] = 0x6F
buf[11] = 0x80
buf[12] = 0xA3
buf[13] = 0x00
buf[14] = 0x00
buf[15] = 0x01 Since everything is shifted, I lost my payload byte

Any idea what’s happening? This happens consistently over and over. The coordinator and router are in the same room. Both interfaced at 9600 baud. I can’t seem to discover any configuration options that would cause this behavior!

Thanks in advance for any suggestions…

2

Also, I forgot to add that maybe a second afterwards, the 0x34 payload byte comes through with the checksum! It’s like the frame is fragmented.

I may be getting hit with a double-whammy.

3

buf[ 5] = 0x7D huh? Shouldn’t this be 0x13?
buf[ 6] = 0x33 Shouldn’t this be 0xA2?

What you’re seeing is the result of using API=2.

7D is the escape character. That means the following character (0x33) has been XORed with 0x20. Together, 7D 33 is decoded as 0x13, which is what you expected.

My packet-check program (see the pinned posts) may perhaps help with packet analysis.

As a general rule, I’d suggest using API mode 2 only when you really need it - such as when you want end-to-end flow control. Otherwise API mode 1 works just fine, and is easier to work with.

4

WHOA!!

Wow man, thank you so much - it would have taken me a long time to discover that (if ever!).

Kudos to you, and thanks again. You made my day.