Need Help with Series 2 Xbee API

XBee & XBee Gateway XBee - Zigbee
1

Ok, I first want to make clear that I am a high school student with little to no formal education in electronics/programming. Despite this, I have constantly tried to challenge myself but I seem to have run into a roadblock:

I have gotten the Xbees to communicate in AT mode but after switching them to API mode I am unable to send any data between the two. I know API mode is working since I was able to successfully able to execute an AT command and I think the problem with transmission is not the xbee’s but mine. Here’s the packet I’m sending to the first xbee:

0x7E 0x00 0x0E 0x10 0x52 0x000000000000FFFF 0xFFFE 0x01 0x00 0x48 0x49 0xC

Both Xbee’s are on the same PAN ID, and Xbee 1 is set with Coordinator Firmware and Xbee 2 is set with Router Firmware.

What am I doing wrong?

I’d love an tutorial on Series 2 API, I can’t seem to find any

Thanks in advance for any help,
Regards,
Harrison

Message was edited by: HarrisnHJones

1 Like
2

It is not clear from your post how you are doing this. If you are typing the data as you have shown it here then it will not work. Once you start using packet mode then the data you send has to be raw hex data, not ascii so your packet should look like this:-

7E000E1052000000000000FFFFFFFE010048490C

This is the binary data and the easiest way to send it to the modem is in a file. You need a hex editor to build the file. If you are using Linux then you can use cutecom to directly send the data in hex form.

This is a packet to send 7 X FF bytes out of the RS232 on a remote module whose address is 13A200 40086EA4

If you are in API mode 1
7E 00 12 00 01 00 13 A2 00 40 08 6E A4 04 FF FF FF FF FF FF FF F2

If you are in API mode 2
7E 00 12 00 01 00 7d 33 A2 00 40 08 6E A4 04 FF FF FF FF FF FF FF F2

This packet does work fine.
This exhausts my knowledge :slight_smile:
If I misunderstood your problem then apologies.

1 Like
3

Update:
Yes, my checksum was wrong. Thank you both for pointing that out!

But, in other news… IT WORKED!! Kinda… I got a response this time from the sending Xbee. It sent me back a Zigbee Transmit Status API Packet. It seems that somehow it couldn’t find the address(error 0x24 “address not found”). I quickly said “nay nay” and looked at the modem info for the other Xbee. To my knowledge, my packet’s destination address is correct. Any help? (I’ve included a screen shot of my X-CTU’s modem readout for both the transmitting Xbee and the receiving Xbee)

Here’s my packet and the response:
My Packet: 7E 00 12 10 01 13 A2 00 40 0A 3E B7 A6 2F 01 00 FF FF FF FF FF 29
Response: 7E 00 07 *b 01 2F 01 00 24 02 1D

I’m thrilled that I got even though the response told me I failed :stuck_out_tongue:

1 Like
4

Hey, I’m back.
I’ve redone my entire packet to reflect series 2 API. Why isn’t it working? :frowning:

Here’s the packet:
7E 00 12 10 01 13 A2 00 40 0A 3E B7 A6 2F 01 00 FF FF FF FF FF D6

And a brake down:
7E - Start
00 - Length MSB(0)
12 - Length LSB(18)
10 - API Identifier
01 - Frame ID(Randomly: 1)
13 A2 00 - 64bit ID MSB
40 0A 3E B7 - 64bit ID LSB
A6 2F - 16bit MSB,LSB
01 - Broadcast Radius(1 hop)
00 - Options(0)
FF FF FF FF FF - Data(5 bytes)
D6 - Checksum

I assume the checksum is wrong. Am I simply missing something?

1 Like
5

Update:

I GOT IT TO WORK!!! Yippie… As it turns out, My 64bit address was in fact a 48bit address(I left out 2 bytes[00]) When I corrected my error it worked like a charm. Now for my next question, how do I recieve the RSSI levels of the packet? Do I have to use the RSSI PWM or can I get it as part of a RX Packet?

Thank to everyone who helped me!

1 Like
6

If you have enabled the API mode by command ATAP 1 or ATAP 2
or by Modem Config page the, in X-CTU, then don’t forget to checkout the “Enable API” in PC setting. Otherwise what ever you type will not be received to other nodes correctly.

1 Like
7

Thanks for that information, seems to make sense. Sadly, I’m going to need a litle more. Firstly, I am sending my data using the “assemble packet” function in the X-CTU program in HEX. Secondly, as far as you post goes: You mentions that the packet you gave me only works for the remote module whose address is 13A20040086EA4. How do I find out my modules remote address? Is it the serial number high and low? Also, do I have to do anything special since one of my devices(the transmitting one) is a “coordinator” and the receiver is the “router”?

Also, in the above post, what format are you using to send the TX packet? I can’t seem to find that exact format.

Quick Note: I reset my modules in AT command mode so I could easily read some values. The SL and SH and MY of my coordinator is as follows:
AT SH
13A200
AT SL
400A3EB6
AT MY
0

The same output for my router is as follows:

AT SH
13A200
AT SL
400A3EB7
AT MY
A62F

How would I construct an API packet send data from the Coordinator to the router using those values?

Thanks(Alot) for the help,
Harrison

Message was edited by: HarrisnHJones

1 Like
8

OK, Well first off I do not use Microsoft products (calling it software is a bit too hard for me:)) so I haven’t used the X-CTU programme other than to upgrade the firmware on all my modules.

I am using just a straightforward terminal software to send data to the Zigbee module, this can be done with the X-CTU software too.

I will leave the SW up to you.

This is how to make the packet manually.
7E 00 12 00 01 00 13 A2 00 40 08 6E A4 04 FF FF FF FF FF FF FF F2

That is the packet as posted, it is made up of

7E A packet
00 12 it’s length
00 API identifier (packet to go)
01 frame ID
00 13 A2 00 MS destination address
40 08 6E A4 LS destination address
04 Broadcast PAN ID
FF FF FF FF FF FF FF Data to send
F2 checksum

For your data this would be

7E A packet
00 12 it’s length
00 API identifier (packet to go)
01 frame ID
00 13 A2 00 MS destination address
40 0A 3E B7 LS destination address
04 Broadcast PAN ID
FF FF FF FF FF FF FF Data to send

With the change of data the checksum has to be recalculated as follows

FF-(00+01+00+13+A2+00+40+0A+3E+B7+04+FF+FF+FF+FF+FF+FF+FF)
This equals 80D, keep only the LS 8 bits (0D)

0D checksum

Before you can do this you have to enable API by entering command mode +++, sending ATAP 1. This will turn on the API, it is 0 by default ie disabled I think

I am about half a day in front of you programming these things, or maybe half a day behind. I haven’t got as far as coordinator and end units yet :slight_smile:

Here are some more command packets, not address specific, just to get info from the unit connected to the PC.

Command packets

7E 00 04 08 52 41 43 21 Apply changes made with previous packets
7E 00 04 08 52 57 52 FC Write settings to NV RAM
7E 00 04 08 52 4E 44 13 Node discover

7E 00 04 08 52 44 4C 15 Get destination address low
7E 00 04 08 52 44 48 19 Get destination address high
7E 00 08 08 52 44 4c 40 08 6E A4 BB Set destination address low to 40086EA4

7E 00 04 08 52 41 50 14 Get API mode
7E 00 05 08 52 41 50 00 14 Set API mode to 0, no API
7E 00 05 08 52 41 50 01 13 Get API mode to 1, API mode
7E 00 05 08 52 41 50 02 12 Get API mode to 2, API mode with escape

7E 00 04 08 52 53 4c 06 Get sending address low
7E 00 04 08 52 53 48 0A Get sending address high
7E 00 04 08 52 50 4c 09 Get power setting
7E 00 04 08 52 56 52 FD Get firmware version of the modem, we are using 1083
7E 00 04 08 52 56 4C 03 Get firmware version of the modem, more info, doesn’t seem to work
7E 00 04 08 52 45 44 1C Energy scan
7E 00 04 08 52 48 56 07 Get hardware version, eg 1809 on this one
7E 00 04 08 52 43 54 0E Get command mode timeout, Don’t really need this as we are using packets and command mode is not needed
7E 00 04 08 52 50 52 03 Get state of pull up resistors, enabled or disabled, default enabled

1 Like
9

Thanks for all the information. All the commands(except sending information :frowning: ) work! :slight_smile:

As far as sending packets. I have the sending Xbee in API mode(through firmware) and the recieveing Xbee AT mode and I sent it the packet you gave me:
7E 00 12 00 01 00 13 A2 00 40 0A 3E B7 04 FF FF FF FF FF FF FF 0D and that didn’t work. So I through that maybe it was because the PAN ID on the packet was wrong, my pan ID is 234(I think, which is EA in hex?) so I recalculated(or tried to) the checksum and got the following packet: 7E 00 12 00 01 00 13 A2 00 40 0A 3E B7 EA FF FF FF FF FF FF FF 27 which also didn’t work. I really wish I knew what I was doing wrong.
Again, Thanks for any help and special thanks to Mjolinor for all the help so far,
Harrison

Message was edited by: HarrisnHJones

1 Like
10

I think you need the receiving modem in API mode.

Your checksum is correct, it looks good to me but I am not an expert :frowning:

We all wish we knew what we were doing.

Message was edited by: Mjolinor

1 Like
11

Where did you get your information? I can’t find a reference to that specific API structure. As expected, I was again unable to send data to the other xbee :frowning: I’ve looked through the Xbee 2 Documentation and all I can find is a reference using the API identifier 10(hex).

Regards,
Harrison

1 Like
12

From the Xbee pro series one documentation

http://www.digi.com/support/identifyfamily.jsp?tp=1

I don’t know the difference between the two series. I am not deep enough in to know the specifics yet.

If your packet is technically correct, ie checksum OK, start stop length and so on, never mind what the packet is supposed to do, then the modem will respond, if anything is wrong with the packet itself then the modem will just throw it away and not reply with anything.

1 Like
13

Ah… Ok, that might have been why your suggestions didn’t work :frowning: When I contacted Digi directly they claimed that Series 1 and Series 2 don’t play well with the same API. I’ve attached a picture of a series 2 transmit API. Could you help me construct a transmit packet using that picture?

I tried to construct such a packet and failed earlier :frowning:

Thanks,
Harrison

Message was edited by: HarrisnHJones

1 Like
14

Is that jpg taken from a document that you have?
If so do you have a link to it?

It seems to be not too different apart from the inclusion of 64 and 16 bit addressing in the same API identifier. The document I have has separate identifiers for 16 (01) and 64 (00) bit addressing, your API identifier covers both and yours has a byte for number of hops. Your byte 17 also does extra things that it doesn’t in the series one.

I think that the documentation truly sucks for these things unless I am missing a number of pages somewhere on their homepage. There just is not enough information available.

Thus far, if I don’t find more information, it’s looking like I will not be using these devices and I am going to have to go and find something else to do what I need.

As far as I can tell you should be able to make the packet in the same way as I did using this format.

** Found the file on the digi FTP site

Message was edited by: Mjolinor

1 Like
15

Our Support site underwent a transition recently and things like documentation, etc are still being tweaked and added. It will get better, I promise you… There are also a number of documents which are in the pipeline to be released soon.

In the meantime, if there’s a specific doc you’re looking for but having trouble finding, please let me know and I’ll see if I can find it for you.

1 Like
16

I think your checksum is wrong.

Spreadsheet attached, it isn’t pretty and it’s fairly basic but it seems to work OK.

1 Like
17

Yes it appears that your checksum is wrong. It looks like you forgot to subtract the LSB from 0xFF (0xFF-0xD6 = 0x29).

1 Like
18

Send an ATND packet and see if your coordinator finds the one you are trying to talk to.

1 Like
19

Mjolinor - Thank you sooo much for that excel file! It’s really useful.

As to the results of the ATND. I send the ATND API Packet and got the following response:

Response: 7E 00 19 88 10 4E 44 00 A6 2F 00 13 A2 00 40 0A 3E B7 20 00 FF FE 01 00 C1 05 10 1E FA 7E 00 05 88 10 4E44 00 D5

After reading this packet(and barely understanding it - obviously need to read the manual more) I see that the sending Xbee found the other Xbee since I can spot 13 A2 00 40 0A 3E B7 which is the other Xbee’s 64bit address.

I am now assuming that something is wrong w/ the 16bit address I’m sending.

Any suggestions?

1 Like
20

If you are having problems with using a specific address you may want to try sending to the default address (0xFFFE). The Tx_Status packet will return to you the 16 bit address of the remote in question.

1 Like