Are API Packets different for Series 1 vs Series 2

I am trying to copy an application where temperature data is sent to an Arduino board using Xbees. The original project used series 2 Xbees, I’m using series 1 and it doesn’t seem to be working. The packet I get back is:

7E 00 0A 83 00 01 20 00 01 04 00 03 FF 54

At first I had the Xbees set with AP=0, then I tried it with AP=1. More details about this issue can be found and the arduino forum:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264655063

I’m wondering if the problem is that Series 2 returns packets differently then series 1.

–Scott

Well, the packet you posted looks like a reasonable one for an 802.15.4 device. Here’s how the packet-check program describes it:

[john@eccles ~]$ packet-check
API Packet analyzer version 0.4 for Series 1 XBee
Enter packet: 7E 00 0A 83 00 01 20 00 01 04 00 03 FF 54

Packet: 7E 00 0A 83 00 01 20 00 01 04 00 03 FF 54
7E // Correct packet header byte
00 0A // payload length (decimal 10)
83 // Packet type: input line states with 16-bit source address
00 01 // 16-bit source address
20 // RSSI value
00 // Broadcast options
01 // Sample count (decimal 1)
// Sample set 0
04 00 // channel indicator
03 FF // A-D value for DIO1 (decimal 1023)
54 // checksum - correct

That looks pretty reasonable.

There are differences in packets between different XBee models, but this packet seems to check out ok.

So: could you expand on what “the problem” really is?

The project I am copying has a temperature sensor hooked up to pin 19 on the Xbee transmitter. The code I copied (you can find it here) is supposed to figure out the value of Pin 19 and puts it into a variable called ‘reading’, but the value is zero. I measured the voltage on pin 19 on the TX and it’s about 1.8. The code used to decipher the Xbee packets is too advanced for me to follow. The author is shifting bytes and doing OR operations, I have no idea why.

–Scott

Ah, yes. The code you have is for a Series 2 XBee - it’s looking for packet type 0x92, whereas the packet you’re receiving is the series 1 equivalent with packet type 0x83. And the layout of those two packet types is different, so changing 0x92 to 0x83 in the code wouldn’t work on its own.

In my earlier post I implied that the packet type should be common to series 1 and series 2. Sorry - I was wrong in that.

The other giveaway is that looking at the picture in the link you supplied to the original project, “series 2” is clearly stamped on the XBee chip :slight_smile:

So you need to find or write some series 1 code, or modify the code you have.

It looks as though there’s something else wrong as well, because in your packet the A/D reading is 0x3ff. That’s a full-scale reading, indicating a high voltage. What do you have the VREF pin connected to? Usually that pin gets connected to the 3.3V power rail, in which case 0x3ff corresponds to an input voltage of 3.3V (or whatever voltage your regulator is actually delivering). If VREF is disconnected, that might explain the 0x3ff reading. (Series 2 XBees have an internal reference of 1.2V, but series 1 XBees need the external reference voltage.)

Does that help?

I knew the example project was series 2. Thanks for confirming there is a difference in the packets. Where can I find documentation on how this packet is structured? I read through the Xbee product manual and it had some stuff, but none of it seemed to match my packet. In your earlier reply to me you broke down the section of each packet, I’d like to have something that tells me what each byte is.

Is 03 FF the analog value on Pin 19 of the TX Xbee? Regarding your VREF question, I temporarily took everything apart and I don’t remember how I had this connected. When I put it back together I’ll pay attention to this.

What API mode do you recommend I put the Xbees in? I tried AP=0 and AP=1 and it didn’t seem to make a difference. Does the API mode only matter if I am sending commands to the XBee, and in AP=0 I would send modem command and if AP=1 I would send API commands? I new to this, so my question may not even make any sense.

–Scott

You can find the information on how the packet is structured in the product manual. It’s the I/O data packet. You can also cross-check what you find there with the info in my cookbook, but it’s the product manual that has the authority.

In the packet you posted, the 0x3ff value was indeed what it was reporting as the A/D value. And on examination of the packet, yes it was pin 19 that was being reported.

Do check the VREF connection. I suspect this may be an important piece of the problem…

As for the API mode, that would be a separate question. in my own application I use AP=1, but there’s no reason to suppose that what what works for me will be what’s right for you. Perhaps best not to worry about this until you’ve got the basic stuff working.

Thanks. This was a big help. I’ll give it another try this week. After thinking about it some more, don’t think I had VREF connected.

–Scott

Just to add.
The AP mode is for the serial interface.
AP=0 is the 'transparent mode, serial in to the same serial out at the destination.
For AP=1 or 2 the serial in must be an API packet.
For sending the state or value of an IO/analog pin the AP mode doesn’t matter.

The Digi docs are a bit daunting at first but all the information is there. Just take your time and study the API frames to learn how to decode a packet.