I am attempting api between two xbp24 modules. They are different versions: base is 1084, remote 10e6.
I can send packets between them in non_api mode. As far as I can tell I am doing everything proper as per
arduino and aeropic. After sending commands below, all of which return OK ( except atai which returns 00
and atnd which returns ).
I send from base a message with ‘hello’ as noted. Nothing is noted or received at either end.
Then from base I send a ‘tx_request’ as follows. ‘hello’ is 68 65 6c 6c 6f
7e 0 a 1 1 0 2 0 68 65 6c 6c 6f e7
I also tried the 64 bit tx request as per http://ftp1.digi.com/support/utilities/digi_apiframes.htm.
The following is same bytes as created on web site ( perhaps is required? )
7e 0 13 10 1 0 13 a2 0 40 5d cf 52 0 2 1 0 68 65 6c 6c 6f 64
Also it’s interesting that altho I can send direct ( no_api ) packets ok, the ‘configuration example’
in your pdf file ‘Product Manual v1.xEx - 802.15.4 Protocol’ does not work.
I feel that the problem is the nodes do not know about each other and I’m doing something wrong in
their ‘discovery’.
Thank you. I changed one module and updated both to latest version 10e8. For first time, I see an api response at far end, but it has invalid checksum and is unrecognizable. Also the near end does not generate a ‘tx status’ or anything else. I tried to follow method of http://code.google.com/p/xbee-arduino/downloads/detail?name=xbee-arduino-0.2.1.zip&can=2&q=. It says remote must have ‘my’ address of 0xffff and they use byte_stuffing. Here’s my setup:
Then I send another ‘atnd’ from the server and receive a correct response:
FFFF.13A200.405C7EDE.24.hand_held…
( where the ‘.’ above are 0x0d )
Then I send a ‘hello’ message. The byte_stuffed version is follows:
7e 0 10 0 0 0 7d 33 a2 0 40 5c 7d 5e de 0 68 65 6c 6c 6f 3e
where there were two bytes which were stuffed.
The response at the remote was
7e 0 a 3f 0 1 24 0 68 65 6c 6c 6f 45
which includes ‘hello’ which is 68 65 6c 6c 6f.
This response is same when I change ‘my’ at remote to 2.
I have four questions:
What does ‘3f’ in the response at remote mean?
Why is checksum incorrect?
Why do I not receive a ‘tx_status’ or anything else at server?
3f is an illegal packet type, so something is badly wrong here.
I’m guessing maybe some bytes have been dropped between the remote and its controller. No, that’s not it. See below.
That’s because in your request packet you set the frame id to 0, thus suppressing the acknowledgement packet.
Patience, determination and a lot of strong coffee
Try setting the frame id to something other than 0, and you should get tx status back. I’m guessing it will tell you that everything worked.
Thing is, this packet would make sense:
Packet: 7E 00 0A 81 00 01 24 00 68 65 6C 6C 6F 45
7E // Correct packet header byte
00 0A // payload length (decimal 10)
81 // Packet type: RX with 16-bit source address
// Valid for 802.15.4
00 01 // 16-bit source address
24 // RSSI value
00 // TX options
// RX data (5 bytes)
68 // received data ‘h’
65 // received data ‘e’
6C // received data ‘l’
6C // received data ‘l’
6F // received data ‘o’
45 // checksum - correct
Compare it with the packet you saw. The only difference is that the packet type of 81 has been mangled into 3f. That didn’t happen inside the xbee, so it must have happened in whatever software you have receiving the packet.
One possible clue: the 81 byte is the only byte in the packet that has the top bit set. So maybe something is trying to interpret byte values as signed, and getting confused that way?
I’d suggest taking a good look at what’s happening between the DOUT pin of the remote and the display on which you’re seeing the garbled packet. Assume that a correct RX packet is emerging from DOUT, and see what could be garbling it.
