I’m doing basic testing with 2 XBee, trying to understand the API mode. I’ve got couple of questions.
Setup is :
1 Xbee connected to an embeded linux box. It is Setup as coordinateur
1 Xbee with only VCC= +3.3 / GND pins connected ( via an Arduino PRO 3.3 VCC / GND to get power supply). Setup as End Device.
API mode is activated on both.
On the Linux box where the coordinator is connected, I run a short C prog to read characters coming from /dev/ttyS2 (where the XBe is connected)
I’ve got (repeating for a while) :
7E 0 A FFFFFF83 0 1 5E 0 1 0 B 0 B 6
7E 0 A FFFFFF83 0 1 5E 0 1 0 B 0 B 6
7E 0 A FFFFFF83 0 1 58 0 1 0 B 0 B C
…
From the Xbee Product Manual :
Byte 1 : 7E : Start delimiter
Byte 2 : 0 : Lenght (MSB)
Byte 3 : A : Lenght (LSB)
Then, we should have the Frame Data at Byte 4. Doc is mentionning Bytes 4-n.
What is n ?
How to decode the frame data ?
I’m stuck with this.
FFFFFF83 0 1 5E 0 1 0 B 0 B
From the doc : Byte 1 : cmdID, Then cmdData
I don’t find FFFFFF83 from the doc (there are 0x08, 0x09, 0x88, 0x00, 0x01, 0x89, 0x80, 0x81)
Some months ago in this forum I posted a packet-check program to help with questions like this. It’s a Tcl script, and I’m attaching an updated version with one small error correction. It’s free for you or anyone else to use.
Here’s what the program has to say about the first packet you posted:
[john@eccles ~]$ packet-check
API Packet analyzer for Series 1 XBee (version 0.2)
Enter packet: 7E 0 A FFFFFF83 0 1 5E 0 1 0 B 0 B 6
Packet: 7E 00 0A FF FF FF 83 00 01 5E 00 01 00 0B 00 0B
7E // Correct packet header byte
00 0A // payload length (decimal 10)
FF // Unknown packet type
Which I think confirms what you already thought: the first FF is taken as the packet type, and it’s not a legal value.
However, the plot thickens. Here’s the output if I miss out the FF bytes:
[john@eccles ~]$ packet-check
API Packet analyzer for Series 1 XBee (version 0.2)
Enter packet: 7E 00 0A 83 00 01 5E 00 01 00 0B 00 0B 06
Packet: 7E 00 0A 83 00 01 5E 00 01 00 0B 00 0B 06
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
5E // RSSI value
00 // Broadcast options
01 // Sample count (decimal 1)
// Sample set 0
00 0B // channel indicator
00 0B // input line states
06 // checksum - correct
Is that more like what you were expecting?
If it is, then maybe you should take another look at your C code. I could be completely wrong, but this is my guess at what’s happening:
Your code reads an 83 byte as a signed character value.
That value then gets stored (or otherwise interpreted) as an int (32 bits). The 83 value happens to be the only value in your packet with the high bit set, and it gets converted to a 32-bit negative integer: FFFFFF83.
So the printout makes the packet look wrong, when in fact it’s a perfectly good packet.
If you take care to treat bytes read from the xbee as unsigned characters, perhaps that problem at least will go away.
Your other question (what is n?): I think the documentation just uses n to refer to whatever the packet length is, which of course depends on packet type as well as other things.
Hope that helps.
Message was edited by: johnf
(forgot to increment the program’s version number the first time)
Those aren’t documented in the 1xAx manual, but you’ll find them in the 1xCx revision (available from the Digi site). They’re the remote AT command packet and the remote AT response packet. With them, you can access and change settings on remote Xbees.