This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TI CC2520 and XBee S2C communication issue

Other Parts Discussed in Thread: CC2520, CC2538

I have a network with 3 devices:

  1. Digi XBee S2C module acting as network coordinator
  2. Digi XBee S2C module acting as router
  3. 3rd party device based on TI CC2520 chip and ZigBee 2006 stack acting as end device connected to coordinator directly

I am able to make all devices join the network.

Sending Explicit Addressing Command from XBee node to XBee coordinator I am able to get data coming our of coordinator UART. 

Sending packets from TI end device, I can packet in RF, but without Acknowledgement packet, and cannot get any data coming in XBee UART.

I have noticed that just after joining coordinator starts to send periodically NWK Leave command to the TI node (see captured packet below).

Why it is happening? Is it some stack compatibility issue? How to solve it?


[11:36:20.699342] Leave 61-88-21-DE-5B-B8-96-00-00-09-10-B8-96-00-00-01-58-38-11-91-40-00-A2-13-00-04-60-FF-FF
Frame Information: (29 bytes)
Packet Number: 478
Protocol: ZigBee
Timestamp: 11:36:20.699342
Time Delta: 0.001888
Channel: 26
Length: 29
Link Quality: -34 dBm
Source: USB8621
Layer: NWK
Status: Normal
MAC Header: (9 bytes)
Frame Control: 0x8861
···· ···· ···· ·001 = Frame Type: [0x1] Data
···· ···· ···· 0··· = Security Enabled: [0x0] No
···· ···· ···0 ···· = Frame Pending: [0x0] No
···· ···· ··1· ···· = Acknowledgement Request: [0x1] Yes
···· ···· ·1·· ···· = Intra-PAN: [0x1] Yes
···· ··00 0··· ···· = Reserved: 0x0
···· 10·· ···· ···· = Destination Addr Mode: [0x2] 16-bit Short Address
··00 ···· ···· ···· = Reserved: 0x0
10·· ···· ···· ···· = Source Addr Mode: [0x2] 16-bit Short Address
Sequence Number: 33
Destination PAN ID: 0x5BDE
Destination Address: 0x96B8
Source Address: 0x0000
MAC Payload: (18 bytes)
NWK Header: (16 bytes)
Frame Control: 0x1009
···· ···· ···· ··01 = Frame Type: [0x1] Command
···· ···· ··00 10·· = Protocol Version: 0x2
···· ···· 00·· ···· = Route Discovery: [0x0] Suppressed
···· ···0 ···· ···· = Multicast Flag: [0x0] Unicast or Broadcast
···· ··0· ···· ···· = Security Enabled: [0x0] No
···· ·0·· ···· ···· = Source Route Included: [0x0] No
···· 0··· ···· ···· = Destination IEEE Address Included: [0x0] No
···1 ···· ···· ···· = Source IEEE Address Included: [0x1] Yes
··0· ···· ···· ···· = Device Initiator: [0x0] No
00·· ···· ···· ···· = Reserved: 0x0
Destination Address: 0x96B8
Source Address: 0x0000
Radius: 0x01
Sequence Number: 88
Source IEEE Address: 00:13:A2:00:40:91:11:38
NWK Payload: 0x6004
NWK Command ID: [0x04] Leave
Leave Options: 0x60
···0 0000 = Reserved: 0x0
··1· ···· = Rejoin: [0x1] Yes
·1·· ···· = Request: [0x1] Yes
0··· ···· = Remove Children: [0x0] No
MAC Footer: 0xFFFF
Frame Check Sequence: 0xFFFF

  • This problem might be caused by different security setting between your XBee coordinator and 3rd party device based on TI CC2520 chip and ZigBee 2006 stack acting as end device .
  • I found that the reason was in incorrect cyclic sleep period parameter on XBee as coordinator. It was too small for polling period of end device.
  • It's good to know you solve the problem and Thanks for sharing your solution.
  • Hi pananela,

    We are also facing the same problem

    what time period you set at coordinator side ?

    pls find  logs file

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/0456.Xbee-logs.7z

    pls help

    Thanks in advance

  • Hi ,

    I don't think that you have the same problem, as I didn't found any NWK Leave packet in your sniffer log. You probably have some issue with Identification mode, but this is different topic.

    As for polling interval, it can be defined from your sniffer logs as 2 seconds (see screenshot below). As far as Data Request packets get Acknowledgment packets in response, communication with sleeping device is OK.

    As for required settings on XBee side (coordinator), there are 2 parameters for that purpose: SP (Cyclic Sleep Period) and SN (Number of Cyclic Sleep Periods). As far as poll timeout (see screenshot below) is larger than sleep period of your end device, communication should be fine. For example, in your case I would assign SP to 0xD0 (2080 ms) and SN to 0x01, which will give poll timeout above 6 seconds (enough to be on safe side). For small static networks it should not be a problem to set this value even large.

  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/2021.Xbee-logs.7zthank you

    I really appreciated your support

    but i am not able to get RF data frame from the end device

    In CC2538 as a ZC - all the communication as per desire - ZC and ZED works fine

    But In Xbee- S2c As a ZC - I am not getting main RF data frame which is 65 byte

    i have attached both the logs here - pls help

  • I am not sure what you are trying to do and what exactly the problem you are facing, but seems it has nothing to do with current topic, which is about polling.
    I suggest you to create separate topic with verbose description of your issue. As it involves XBee, I think it is reasonable to create similar topic on Digi Forum.

  • Thank for update

    I would like to confirm about the Xbee S2C supports Temp sensor measurement cluster - Cluster ID- 0X402 or not?

    If it supports then i have to look in to different area

    i am doubtful about the Xbee support to cluster 0x402

    if, it supports cluset 0X402 ZCL then 

    What setting you did in the XCTU tool pls share the snippet

  • Hi ,

    XBee itself doesn't have application running on board. It acts as radio with ZigBee stack. So, there should be no problem with compatibility with particular cluster ID as XBee simply forwards encapsulated APS frame to the host controller over serial interface. As I understood, you are experiencing problem with passing through messages to the serial interface. I would suggest to try AT command AO to be set to 0x03, 0x07 or 0x0B.

    But again, we are solving problem of the product from different vendor and different topic here. Better create new thread in Digi Forum and post link here, so I can follow up.