XBee Obbject Updated

Martin Hebel

While working on the API chapter of the XBee tutorial, I required some updates (fixes!) for the API Object. Version 1.6 is updated fixing and changing a few things for API mode such as local and remote configuration changes.

http://obex.parallax.com/objects/146/

An API test file is also posted with it showing utilization of the methods.

-Martin

Daniel Harris

Cool! Thanks for the update. I'll pull it down and check out what has changed and hopefully learn how to communicate in API mode (not just AT mode) .

Invent-O-Doc

Thanks Martin. This is a really good object. The implementation of the frame based mode makes using that feature really simple. Thanks again!

Martin Hebel

Thanks all, also look for the latest XBee chapter on API that uses the object and example base. It's a wireless forum post from Stephanie.

KurtE

Hi, I am playing around with porting some of my robot code over to the propeller and on some of my robots I use XBees in API mode with my own packet format to talk from a remote control to my robot...

I decided to not reinvent the wheel here and am using your version 1.6 as the lower level code. But I kept losing a lot of my packets. I first verified that the data was making it to the propeller using my logic analyzer (saleae). My first thought was maybe I was overflowing the input buffer of the FullDuplexSerial object as my main data packets with all of the XBee API stuff around them are 18 bytes long, so I downloaded the modified version of the FullDuplexSerial object and increased the buffersize to 128 bytes, but still was missing the data.

So then looking over the XBee code I found the problem. The problem is in the function: RxPacketNow. What happens is that many times multiple packets of data may be received by the XBee between the times that I am processing data. But the code in RxPacketNow starts off:
ptr := 0
Repeat
Char := rxTime(1) ' accept remainder of data
dataSet[ptr++] := Char
while Char <> -1

So it reads everything that has been cached up into it's own buffer, but only processes the stuff from the first message. There are several ways to fix this, my current hacking, starts off like:
ptr := 0
' Need to read the next two bytes to get the length so we know how many
' bytes to read in. There may be multiple packets stashed in the input buffer
' so we don't want to just read everything in here...
_RXLen := (rxTime(2) << 8)+ rxTime(2) ' 2ms should be enough time to receive a byte evan at 9600 baud
_RXIdent := rxTime(2) ' Read in the type of packet byte

repeat _rxLen
Char := rxTime(2) ' accept remainder of data
dataSet[ptr++] := Char


Side note: The two places that call RxPacketNow have some unused local variables defined.

Kurt