Clarification of endienness

According to the Freescale Zigbee library:

All multi-byte fields, such as group ID, cluster ID, attribute ID, etc… are set up in the structures as an array, little endian (low-byte first), because the in ZigBee specification all multi-byte fields are little endian over the air. The HCS08 is a big endian processor, so care must be taken with values that have mathematical meaning such as time

but looking at explicit rx message type 0x91, the profile and cluster are sent MSB first.

I’m wondering who’s right here … and whether or not I should really be using little endian for my ZCL attributes (i.e. multi-byte values in a Read Command Response).

Is this just a doc error in the xbee documentation? It’s a good opportunity for a symmetrical error… if the only thing I ever use are Xbee modules (which is likely) I might never notice if the byte ordering is wrong.


Hello Chris,

Take a look to the Product Manual in page 119 (Sending ZigBee Device Objects (ZDO) Commands with the API):

When sending a ZDO command with the API, all multiple byte values in the ZDO command (API payload) (e.g. u16, u32, 64-bit addresses) must be sent in little endian byte order for the command to be executed correctly on a remote device.

To send explicit frames in Programmable XBee, you have to fill an wpan_envelope_t’s cluster and endpoint fields and send it with wpan_envelope_send(). Take a look to xbee_transparent_serial() function and Transmit Simple Frames example.

Best regards,

Ah okay. The piece I’m working on now is at my coordinator, and it’s not an xbee programmable. It’s just a Coordinator in API mode. What I’m working on is the java agent that talks to this coordinator via serial usb.

I was concerned because in the API mode, things like explicit rx frame and the profile/cluster in the API protocol are documented as big endian, but then once you get to the application layer (ZCL, etc.) they are, per zigbee spec, little endian. This seemed inconsistent to me, but I see now (unless you correct me) that it’s not a problem - the line of demarcation is at the Xbee API packets. Beyond that, it looks like everything will be little endian.