Problems Sending a specific data frame

XBee & XBee Gateway XBee - DigiMesh
1

Hello everyone,

I am trying to send a frame with X-CTU assemble packet. The frame is shown at following:

7E 00 12 01 00 7D 33 A2 00 40 61 50 00 FF FE 00 00 CC CC 00 7D 33 A0

The XBee sending the frame is configured with AP = 2. I am receiving the TRANSMIT STATUS as I sent the frame correctly (7e 00 07 8B 01 FF FE 00 00 00 76) but I am not receiving anything at the destination XBee.

I know that changing the order of the payload, the destination XBee receives the frame without problem.

Does anyone know what I am doing wrong?

Thank you very much in advance,
Juanra.

2

You didn’t say if the destination is an end-device, but the TX Status being good really just means you passed the packet off to another XBee - to the parent in case of a sleep device. If the parent discards the message before the child polls for it (for example because of the SN/SP settign in the parent), then I don’t think you’ll ever know.

3

Sorry for the late answer,

The point is that there are no hops between them (two nodes network size) and they aren’t in sleep mode. They just are sending one frame to another without success, but the TRANSMIT STATUS answer the sent was good.

By the way, TX status means that only one packet has been sent to another xbee? (e.g. in a two-hops network, A -> B -> C, when node A receives the TRANSMIT STATUS means that the packet reach node B, even when the target node was node C).

Thank you in advance,
Juanra.

4

I hope I’m not simply muddying the waters here, but according to the Digimesh product manual packet type 0x01 isn’t a valid option. (In my understanding that packet type is valid only for the 802.15.4 firmware.) The Digimesh manual has packet type 10 for TX request.

On the other hand you did get a response, so maybe it’s valid but undocumented.

Another oddity: in your packet you set the frame id to 00. That should mean “don’t send a response packet”. And yet you got one.

Also, the original frame as you posted it isn’t a legal packet. That could be just because the posted packet has omitted the checksum byte.

I don’t have an answer - I’m just wondering whether there’s more to this than meets the eye.

5

I have discovered that I failed to copy one of the bytes of the frame, so the right frame is:

7E 00 12 10 01 00 7D 33 A2 00 40 61 50 00 FF FE 00 00 CC CC 00 7D 33 A0

Sorry for the mistake, now some of the points that johnf had addressed are solved.

Also, next you can find another example with the same problem:

7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 CC CC 00 7D 33 00 A2 40 77 80 2C 27 21 6C

In addition, if I change the payload generating the next frame, there’s no problem with the send:

7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 A2 CC CC 00 7D 33 A2 00 40 77 80 2C 27 21 6C

Thanks for your help, do you think in another cause?

Juanra.

6

Right. Well, the original packet now looks fine. Here’s what packet-check says about it:

[john@henry ~]$ packet-check -api2
API Packet analyzer version 1.5 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Escape characters enabled (AP=2)
Note: if it prompts for more bytes and you're done, hit return
Enter packet: 7E 00 12 10 01 00 7D 33 A2 00 40 61 50 00 FF FE 00 00 CC CC 00 7D 33 A0

Original packet: 7E 00 12 10 01 00 7D 33 A2 00 40 61 50 00 FF FE 00 00 CC CC 00 7D 33 A0

Unescaped packet: 7E 00 12 10 01 00 13 A2 00 40 61 50 00 FF FE 00 00 CC CC 00 13 A0
7E          // Correct packet header byte
00 12       // payload length (decimal 18)
10          // Packet type: ZigBee transmit request
            // Valid for DigiMesh, ZigBee, Znet2.5
01          // frame id: non-zero so response packet expected
00 13 A2 00 40 61 50 00 // 64-bit destination address
FF FE       // 16-bit destination address
00          // Broadcast radius (decimal 0)
00          // Options: 
            // TX data (4 bytes) [1]
CC          // transmitted data
CC          // transmitted data
00          // transmitted data NUL
13          // transmitted data DC3
A0          // checksum - correct

Notes:
[1] Max 100 bytes on 802.15.4, or 72 on DigiMesh or ZNet2.5

And here’s what packet-check says about your second packet:

[john@henry ~]$ packet-check -api2
API Packet analyzer version 1.5 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Escape characters enabled (AP=2)
Note: if it prompts for more bytes and you're done, hit return
Enter packet: 7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 CC CC 00 7D 33 00 A2 40 77 80 2C 27 21 6C

Original packet: 7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 CC CC 00 7D 33 00 A2 40 77 80 2C 27 21 6C

Unescaped packet: 7E 00 1A 10 01 00 13 A2 00 40 68 6D C3 FF FE 00 00 CC CC 00 13 00 A2 40 77 80 2C 27 21 6C
7E          // Correct packet header byte
00 1A       // payload length (decimal 26)
10          // Packet type: ZigBee transmit request
            // Valid for DigiMesh, ZigBee, Znet2.5
01          // frame id: non-zero so response packet expected
00 13 A2 00 40 68 6D C3 // 64-bit destination address
FF FE       // 16-bit destination address
00          // Broadcast radius (decimal 0)
00          // Options: 
            // TX data (12 bytes) [1]
CC          // transmitted data
CC          // transmitted data
00          // transmitted data NUL
13          // transmitted data DC3
00          // transmitted data NUL
A2          // transmitted data
40          // transmitted data '@'
77          // transmitted data 'w'
80          // transmitted data
2C          // transmitted data ','
27          // transmitted data '''
21          // transmitted data '!'
6C          // checksum - correct

Notes:
[1] Max 100 bytes on 802.15.4, or 72 on DigiMesh or ZNet2.5

So that’s a good packet. I see it has a different destination address to t he first packet: was that intentional?

For your third packet we get:

[john@henry ~]$ packet-check -api2
API Packet analyzer version 1.5 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Escape characters enabled (AP=2)
Note: if it prompts for more bytes and you're done, hit return
Enter packet: 7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 A2 CC CC 00 7D 33 00 40 77 80 2C 27 21 6C

Original packet: 7E 00 1A 10 01 00 7D 33 A2 00 40 68 6D C3 FF FE 00 00 A2 CC CC 00 7D 33 00 40 77 80 2C 27 21 6C

Unescaped packet: 7E 00 1A 10 01 00 13 A2 00 40 68 6D C3 FF FE 00 00 A2 CC CC 00 13 00 40 77 80 2C 27 21 6C
7E          // Correct packet header byte
00 1A       // payload length (decimal 26)
10          // Packet type: ZigBee transmit request
            // Valid for DigiMesh, ZigBee, Znet2.5
01          // frame id: non-zero so response packet expected
00 13 A2 00 40 68 6D C3 // 64-bit destination address
FF FE       // 16-bit destination address
00          // Broadcast radius (decimal 0)
00          // Options: 
            // TX data (12 bytes) [1]
A2          // transmitted data
CC          // transmitted data
CC          // transmitted data
00          // transmitted data NUL
13          // transmitted data DC3
00          // transmitted data NUL
40          // transmitted data '@'
77          // transmitted data 'w'
80          // transmitted data
2C          // transmitted data ','
27          // transmitted data '''
21          // transmitted data '!'
6C          // checksum - correct

Notes:
[1] Max 100 bytes on 802.15.4, or 72 on DigiMesh or ZNet2.5

So that’s another good packet, identical to the second except for the order of bytes in the transmitted data.

There’s no reason visible here why the third packet should work while the second fails.

So now I’m at a loss to make further suggestions. Maybe someone else can help?

Incidentally, if you’d like to check packets for yourself, the packet-check program (which I wrote and maintain) is available through the pinned posts at the top of the 802.15.4 forum. 802.15.4 is my “home” forum, but packet-check is written to cover all XBee models.

7

Thank you very much again,

I knew about your program and it was very useful during the first phases of my development. Thank you very much for your help, great and useful contribution to the community.

The problem seems to appear when I use the payload in the order you saw in the second frame. For any reason, the Xbee does not like the combination “CC CC 00 13 A2”. I tried different configurations several times (using other Xbee, etc) and the result was always the same.

BTW cjxicerains, I’m glad you knew johnf’s work through this post, at least it was useful!

Juanra.

8

Then I’m baffled. I think at this point you should get in touch with the fine folks at Digi Support. Refer them to this thread, and see what they come up with. When you have the answer, it’d be appreciated if you’d post it here for the benefit of others.

Oh, and by the way, cjxcerains isn’t a regular member of the forum. If you visit his profile and compare his other posts, I think you’ll get the idea…