Does XBee S2C support receive option 0x40 (packet sent by an end device)?

XBee & XBee Gateway XBee - Zigbee
,
1

The XBee ZB firmware for S2B modules supported a flag in the receive options byte (of the receive indication frames) which indicated that the message was sent by a sleeping end device. This was bit 6/0x40. That value is not documented for the S2C and I’m wondering if it still exists in some form or another? I’ve never seen this mentioned as an incompatibility between S2B/S2C.

Otherwise I assume it is up to the application to provide an appropriate method of determining whether an extended transmission timeout is required (with no help from XBee).

2

It is not documented for the S2C, but it is still functional. We will notify the right people to get the documentation updated.

3

Thanks for your reply. How certain are you that it IS still implemented in S2C? I’ve tried it with the latest firmware S2C (sleeping ED) -> S2C (C) with both the explicit and non-explicit receive API and the flag is not set (receive options are always 01). I’ve even tried sending a packet from an S2B (sleeping ED) -> S2C (C) with the same result.

4

What do you mean by Receive option 0x40? Can you provide a full API frame of what it is you are referring to?

5

‘Receive options’ is the name of the byte at offset 14 of the ‘Receive Packet’ frame (0x90) or offset 20 of the ‘Explicit Rx Indicator’ frame (0x91). This byte is a set of single bit flags of which bits 0, 1 and 5 are defined in the S2C XBee ZB firmware. This is according to the ‘XBee/XBee-PRO S2C ZigBee - User Guide’.

My question relates to bit 6 (0x40 expressed in byte form) of the Receive options byte. The user guide for S2C does not mention it, while it IS defined in the user guide for S2B modules. From the S2B user guide…

Receive options:

0x01 - Packet Acknowledged
0x02 - Packet was a broadcast packet
0x20 - Packet encrypted with APS encryption
0x40 - Packet was sent from an end device (if known)

Note Option values can be combined. For example, a
0x40 and a 0x01 will show as a 0x41. Other possible
values 0x21, 0x22, 0x41, 0x42, 0x60, 0x61, 0x62.

6

I would suspect it is as Digi generally does not remove functions one it has been established.

7

I’ve verified that receive option 0x40 IS set when an S2B end device (pin sleep) sends a message to an S2B coordinator.

HOWEVER… When I substitute the S2B coordinator for an S2C coordinator (using the same end device), there is no 0x40 indication. I’ve also tried S2C end device to S2C coordinator and S2C end device to S2C coordinator, none of which work either.

So my conclusion is that this feature has been silently dropped from the S2C, making it an undocumented (or at least documented by omission) incompatibility with S2B modules.