Home/Support/Support Forum/Need Help with Series 2 Xbee API

Need Help with Series 2 Xbee API

+1 vote
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
asked Jan 5, 2008 in ZigBee PRO Featureset (and legacy ZNet 2.5) by HarrisnHJones New to the Community (31 points)

Please log in or register to answer this question.

19 Answers

+1 vote
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 :)
If I misunderstood your problem then apologies.
answered Jan 5, 2008 by Mjolinor New to the Community (29 points)
+1 vote
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
answered Jan 5, 2008 by HarrisnHJones New to the Community (31 points)
+1 vote
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 :)

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
answered Jan 5, 2008 by Mjolinor New to the Community (29 points)
+1 vote
Thanks for all the information. All the commands(except sending information :( ) work! :)

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
answered Jan 5, 2008 by HarrisnHJones New to the Community (31 points)
+1 vote
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 :(

We all wish we knew what we were doing.


Message was edited by: Mjolinor
answered Jan 5, 2008 by Mjolinor New to the Community (29 points)
+1 vote
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 :( I've looked through the Xbee 2 Documentation and all I can find is a reference using the API identifier 10(hex).

Regards,
Harrison
answered Jan 6, 2008 by HarrisnHJones New to the Community (31 points)
+1 vote
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.
answered Jan 6, 2008 by Mjolinor New to the Community (29 points)
+1 vote
Ah.. Ok, that might have been why your suggestions didn't work :( 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 :(

Thanks,
Harrison


Message was edited by: HarrisnHJones
answered Jan 6, 2008 by HarrisnHJones New to the Community (31 points)
+1 vote
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
answered Jan 6, 2008 by Mjolinor New to the Community (29 points)
+1 vote
Hey, I'm back.
I've redone my entire packet to reflect series 2 API. Why isn't it working? :(

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?
answered Jan 8, 2008 by HarrisnHJones New to the Community (31 points)
...