Padded payload in zigbee_test.py?

I’m running my first tests with the ConnectPort X2 gateway and our ATMega8-controlled XBee2. On the micro side, I am sending single bytes to the UART (and hence XBee). On the gateway side though, using a tweaked version of Digi’s zigbee_test.py, the arriving payloads are 20 bytes long. Here’s the gateway code:

This example binds to application endpoint 0xe8,

receives a single frame at this endpoint, and

displays the source address and payload

include the sockets module into the namespace:

from socket import *

Create the socket, datagram mode, proprietary transport:

sd = socket(AF_ZIGBEE, SOCK_DGRAM, ZBS_PROT_TRANSPORT)

Bind to endpoint 0xe8 (234):

sd.bind((“”, 0xe8, 0, 0))

Block until a single frame is received, up to 72 bytes:

payload, src_addr = sd.recvfrom(72)

print "src_addr: ", src_addr

print “len(payload): %d” % len(payload)
for index, byte in enumerate(payload):
print “payload[%d] = %s (%d)” % (index, hex(ord(byte)), ord(byte))

and here’s what I see as output:

#> python zigbee_test.py

src_addr: (‘[00:13:a2:00:40:0a:23:98]!’, 232, 49413, 149)
len(payload): 20
payload[0] = 0x8e (142)
payload[1] = 0x47 (71)
payload[2] = 0x0 (0)
payload[3] = 0x13 (19)
payload[4] = 0xa2 (162)
payload[5] = 0x0 (0)
payload[6] = 0x40 (64)
payload[7] = 0xa (10)
payload[8] = 0x23 (35)
payload[9] = 0x98 (152)
payload[10] = 0x20 (32)
payload[11] = 0x0 (0)
payload[12] = 0xff (255)
payload[13] = 0xfe (254)
payload[14] = 0x1 (1)
payload[15] = 0x2 (2)
payload[16] = 0xc1 (193)
payload[17] = 0x5 (5)
payload[18] = 0x10 (16)
payload[19] = 0x1e (30)

Newbie Questions:

  1. Why is the source address showing up in the payload?

  2. More generally, why 20 bytes? What is the structure of this data? Is the so-called payload actually the full Zigbee protocol frame? (I doubt it)

  3. What is special about 72 for the socket recvfrom? Is this the maximum data length?

We’re looking forward to getting this working. Any help is much appreciated.

> and here’s what I see as output:
>
> #> python zigbee_test.py
>
> src_addr: (‘[00:13:a2:00:40:0a:23:98]!’, 232, 49413,
> 149)
> len(payload): 20
>
>
> Newbie Questions:
>
> 1) Why is the source address showing up in the
> payload?
>

(see below)

> 2) More generally, why 20 bytes? What is the
> structure of this data? Is the so-called payload
> actually the full Zigbee protocol frame? (I doubt
> it)

The frame that you are receiving is actually not the byte you sent to the ConnectPort gateway from your ATMega-attached node. There are a number of other frame types that will arrive on endpoint 0xe8 (232) signified by the cluster id field other than data indications 0x11 (17). In the frame above, the indicated frame type (or “cluster”) is specified to be 0x95 (149).

If you refer here:

http://ftp1.digi.com/support/documentation/90000866_C.pdf

On page 69 you will see the frame type and explanation for the message you’ve received. It is a “Node Identification Indicator” and it is sent when some process has pulled down the node identification pin of the XBee ZNet 2.5 module (DIO0).

My guess is that in your ATMega-based design, you have something that can cause a logic transition on this pin and that is why your module is transmitting these messages to the coordinator.

You can disable these messages (if you like) by setting the D0 parameter of the ATMega attached module to 0 and then storing the parameter by sending a WR command.

>
> 3) What is special about 72 for the socket recvfrom?
> Is this the maximum data length?
>

Good question! Yes, 72 bytes is the maximum payload size on a ZNet 2.5 based module. This will actually change a bit with our newly announced ZigBee-PRO compliant modules and so we are going to add a function that will allow folks to query the maximum frame size from the system.

> We’re looking forward to getting this working. Any
> help is much appreciated.

I hope this helps you, if you need any more info please do not hesitate to ask!

Thanks Jordan for the quick and detailed response.

> If you refer here:
> http://ftp1.digi.com/support/documentation/90000866_C.
> pdf
>
> On page 69 you will see the frame type and
> explanation for the message you’ve received. It is a
> “Node Identification Indicator” and it is sent when
> some process has pulled down the node identification
> pin of the XBee ZNet 2.5 module (DIO0).
> My guess is that in your ATMega-based design, you
> have something that can cause a logic transition on
> this pin and that is why your module is transmitting
> these messages to the coordinator.

Yes, that pin is floating on our prototype board. Presumably tying it to either VCC or GND would eliminate these spurious messages?

> You can disable these messages (if you like) by
> setting the D0 parameter of the ATMega attached
> module to 0 and then storing the parameter by sending
> a WR command.

A bit of strangeness here. I pulled the XBee Series 2 chip out of our board and stuck it in the XBIB USB test board. Connecting with X-CTU and reading the modem configuration, it comes back as XB24-B with function set “Zigbee Router/End Device AT”. Under I/O Settings, D0 was enabled. I switch it to disabled and write the parameters back to the chip. Sticking this chip back into our prototype board, the above frames are still coming through, for example (minor change to payload formatting from above) …

src_addr: (‘[00:13:a2:00:40:0a:23:98]!’, 232, 49413, 149)
len(payload): 20
payload[0] = ‘}’ (0x7d, 125)
payload[1] = ‘’ (0x16, 22)
payload[2] = ‘’ (0x0, 0)
payload[3] = ‘’ (0x13, 19)
payload[4] = ‘¢’ (0xa2, 162)
payload[5] = ‘’ (0x0, 0)
payload[6] = ‘@’ (0x40, 64)
payload[7] = ’
’ (0xa, 10)
payload[8] = ‘#’ (0x23, 35)
payload[9] = ‘’ (0x98, 152)
payload[10] = ’ ’ (0x20, 32)
payload[11] = ‘’ (0x0, 0)
payload[12] = ‘ÿ’ (0xff, 255)
payload[13] = ‘þ’ (0xfe, 254)
payload[14] = ‘’ (0x1, 1)
payload[15] = ‘’ (0x2, 2)
payload[16] = ‘Á’ (0xc1, 193)
payload[17] = ‘’ (0x5, 5)
payload[18] = ‘’ (0x10, 16)
payload[19] = ‘’ (0x1e, 30)

In general is the payload shown above the full Zigbee frame? I.e., it contains the entire radio transmission, not just the serial payload data? I’m trying to reconcile the above output with the info on page 70 of the above PDF. Wouldn’t I expect to see the start delimiter? Instead, the first two bytes of the payload seem to be random, changing each time (compare payload shown immediately above with that from my first message).

An aside, I did note in section 8.1 of the above PDF that “The XBee firmware inserts 8 bytes at the beginning of the data payload that represent the 64-bit address of the source module.” Presumably then, even when we get our system working, our single byte messages will arrive prepended with these 8 bytes?

Again, thanks for your help.

Cheers,
Darran.

> On page 69 you will see the frame type and
> explanation for the message you’ve received. It is a
> “Node Identification Indicator” and it is sent when
> some process has pulled down the node identification
> pin of the XBee ZNet 2.5 module (DIO0).
>
> My guess is that in your ATMega-based design, you
> have something that can cause a logic transition on
> this pin and that is why your module is transmitting
> these messages to the coordinator.
>
> You can disable these messages (if you like) by
> setting the D0 parameter of the ATMega attached
> module to 0 and then storing the parameter by sending
> a WR command.

Given that the DIO0 pin is floating in our design, shouldn’t enabling the internal pull-up resistor on this pin stop it from undergoing spurious transitions? Apparently not, since all 13 pullups are seemingly enabled (PR set to 1FFF).

For reference, the PR bitfield "configure[s] internal pullup resistors status for I/O lines. 1=internal pullup enabled, 0=no internal pullup. Bitfield map:

(12)-PWM1,
(11)-PWM0/RSSI,
(10)-CD,
(9)-On/Sleep,
(8)Associate,
(7)-DIN/Config,
(6)-Sleep_Rq,
(5)-RTS,
(4)-AD0/DIO0,
(3)-AD1/DIO1,
(2)-AD2/DIO2,
(1)-AD3/DIO3,
(0)-DIO4

Also, in regard to the notification id pin, DIO0 is 0 but the messages are still coming …

Toggling D0 is not the only way in which you may receive these messages; you may also receive these messages as join notifications when a node becomes associated to the coordinator.

Please see Table 4-05 on page 34 of the 90000866_C.pdf manual for the XBee module.

In any application you’ll need to add some code to differentiate the message types you receive on the 0xe8 (232) data endpoint.