API commands doesn't work

XBee & XBee Gateway XBee - 802.15.4
1

Hi, I’m using a PIC with UART module which communicates with the Xbee module, I use assembler lenguage, when using AT commands all is ok, but I try with several API commands (modem status, for example) and it doesn’t work, I tried sending characters (‘7’ ‘E’…) and hex codes (0x07 0x0E…) checksum for associated status (2) is 0x24, also I tried sending 0x0D at the end, but the UART of the PIC isn’t receiving anything. I looked for it at forum but I have no idea about what is the problem. ¿Any idea?

Thanks very much.

2

The API 8A command frame is a frame you will receive from a unit. It’s not a command that you can send!!

3

The only thing I see is my Xbee version are 1084 and maybe I must update it…

4

Hello.
Is it work in transparent Mode ? What is your PIC model ? If it’s a 5V modele , did you adapt voltage (5V <-> 3.3V) ?

5

I think version 1084 should handle most API commands. Perhaps if you posted the exact command you were sending, we might be able to help more.

Still, I would suggest that you update the firmware anyway. Later versions have more functionality and they have bug-fixes too. If you don’t update the firmware, it’s quite likely that you’ll run into other issues.

6

Hi, the exact command is “7E00028A02240D” Is the API command for associate the XBee (modem status). I tried other API commands, but it is the same.

Thanks.

7

Hi,thanks very much for your help. the XBee is configured in API mode now, ¿must it be in transparent mode? The pic is an 16F876, with UART module and works at 3.3V, AT commands works ok. I used resistors for adapt 5 to 3.3 volts, but it’s the same. I have captured the communication with an protocol analyzer:

http://www.cuelgalo.com/images/1228126295_captura_de_captura_de_datos.JPG

Thanks very much

8

Sorry I was confused about the link of the image, it is for other post.

9

10

I have updated the firmware to 10CD version, AT commands works ok, but API dont work…

11

Thanks, I didn’t realized of that, but I sent other commands, for example 16-bit transmit request : 7E 0007 01 FF FFFF 01 0A 0B + checksum

0007 the length, 01 API identifier, FF frame id, FFFF broadcast, 01 option, 0A and 0B are data, and the checksum is calculated automatically by an software algorithm.

I send it as bytes, no characters.

Message was edited by: Intense

12

Since you’re broadcasting this packet, and also suppressing the ACK in the options byte, I wouldn’t expect much in the way of a response.

Maybe you could try addressing it to one specific Xbee, and with the options byte set to 00 so that an ACK should be returned. That should be more informative.

Also, can you capture the checksum and post it? An incorrect checksum would certainly cause trouble…

13

There is no API 0x01 as far as I know!

14

If you want to use API frame 0x10 (Zigbee transmit Request):
You also have to enter a 64 bit destination address. If broadcast: 0x000000000000FFFF.
And you have to enter the 16 bit network address. If not known or in case of broadcast: 0xFFFE
And you have to enter the Broadcast Radius: 0x00 for max. number of hops
Set the option byte to 0x00 (as 0x08 is not supported)

15

Ah. Well, the last thing I want is to start arguing about this, but according to my reading of the product manual for the 1xCx firmware, packet type 00 is a TX request with 64-bit addressing and 01 is a TX request with 16-bit addressing.

Is it possible that you’re describing the series 2 Xbees, or maybe even some other variant? Or am I just confused?

16

you are right. I’m talking about the series II. Sorry for the confusion.

17

Hi again and thanks for your answers. I try now with “7E0701FF3333000A0B03” where FF is the Frame ID, 3333 the destination address, 00 the options, 0A0B the data and 03 the checksum. The other Xbee is connected to computer with X-CTU software.
Really I don’t know how to use the frameID, maybe this the error…

Thanks.

18

That packet claims to have a length of 0701 bytes, which can’t be true.

19

Sorry, I wrote wrong, it is “7E000701FF3333000A0B03”.
It is supposed that the module will response with an “TX status” API frame with the success or not of the transmission.

Thanks.

Message was edited by: Intense

20

It’s the checksum that’s wrong - for that packet it should be 84, not 03. (Payload bytes and checksum should add up to 0xff (modulo 0x100)).

Hope that helps