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.

CC2530 ZStack Incompatibility with Digi XBee-Pro modules

Other Parts Discussed in Thread: CC2531, CC2530, Z-STACK

Hi all,


I am having a communication problem between the CC2530 end device and a Digi XBee-Pro module coordinator and router.  The CC2530 runs ZStack 2.5.1a, and it uses Zigbee 2007 Pro.  To my knowledge, the Digi modules also use Zigbee Pro.  It appears to me that when the "NWK Source Rte Subframe" is present in the network payload from the Digi modules that the CC2530 end device cannot process the message properly.  If you look in the attached .psd file collected by a CC2531, you will see that an end device (address 0x7E05) does not properly receive an application data packet routed to it by 0xAEBF.  (It has a length of 70 and you can use the filter condition "DAD=0x7E05" to see it easily.  Add "SAD=0x7E05" to see that it is not acknowledged at the APS level.)  You can tell because end device does not receive the packet properly because it does not send a APS acknowledgement like it should (the proper bit in the APS frame control field is set under the improper "Ext. hdr" label).  The application running on the end device also times out because it does not see the message at the application level.  It then connects to the coordinator to try the message processing again.  When it connects to the coordinator as address 0x5AF6, the coordinator will send a message of length 66 with the same application packet data, and the end device will acknowledge it at an APS level.  The difference between the two packets I mentioned is the "NWK Source Rte Subframe", but it appears that makes a difference in reception of the packet.


Using a TI coordinator, I was able to see the proper APS acknowledgement and reception.  The network payload for the application data packet sent to the end device did not contain the network source route subframe (or the IEEE destination or source addresses either).


We have a strong desire to have legacy compatibility with an already existing product composed of these Digi modules.  I am thinking that the Z-Stack software may not handle the network source route subframe properly, because I do not think I touched the handling of the network frame (nor do I think I can because TI does not give you the source).  I could be wrong, though.  I do not have extensive knowledge of Zigbee.  Please let me know if you need any more data or what can be done.


Thanks,
Jeremy Dwyer

7142.CC2530DigiPackets.psd

  • After doing a google search, it seems that it is related to this question:  http://e2e.ti.com/support/low_power_rf/f/158/t/217166.aspx.  It appears that Z-Stack actually does the right thing in dropping the packet in the first case.  If you look in the Zigbee specification at section 3.6.3.3.2, if the relay index subfield is something other than 0, then the network address at the relay list index must match the network address of the receiving device - otherwise, it is dropped.  (This section is in the other blog.)  Unfortunately, the Digi modules are sending the wrong thing.  They are sending an index of 0xFF, which is not even a valid relay index?

    It appears that in this blog at the bottom, they requested that TI allow for more tolerance on acceptance of a source routing packet, such as checking the network address before the relay index.  Does TI have anything to say regarding this?

  • yikes, this is making me worried!  I have a few legacy Xbee networks that need to work with a cc2530 end point.   Is anybody out there using an Xbee Coord and routers with cc2530 endpoints?

    I've tried to read as many threads as I could and it seems like it is related to the Xbee modules sending some strange values.  Does anybody know if the z-stack code can be hacked to remove the incompatibility between what is supposed to be a Zigbee Pro 2007 network??

    thanks!

  • Hi Rob,

    I have hacked the mac code below Z-Stack to override this behavior.  What I did was I had to insert a hack into mac_rx.c to detect if there is a source route subframe, and override the relay index to 0 before Z-Stack receives the packet from the mac.

    Sorry, I don't know if I am allowed to disclose my source, since this is work for another client.  I will tell you that this hack is in the function rxFcsIsr.  You will have to parse the received NWK frame in pRxBuf to find the relay index in the source route subframe, and then set it to 0.  Documentation from Zigbee will disclose the packet format.

    Jeremy

  • Amazing Jeremy, thank you!

    I will examine the code today and test it when I can.  Besides for the Leave Cmd problem you identified, are there any others you can tell me about to avoid pain later on?

    Did you find after you made these changes that the network that uses xbee coords and a mix of xbee/cc2530 routers and endpoints is stable?

    thanks!

  • No, I do not think I have found any other incompatibility problems besides the two I posted in the TI blogs  - the leave command and the source route packet rejection.

    It looks to me that the XBee coordinator and CC2530 routers interact properly after fixing the two incompatibility issues.  The client I am working for and I have not seen any other problems in testing so far.  I think I have had XBee routers on the network and have not noticed any problems, but I am not positive on that.

  • I follow your step but I don't know Where can I find relay index and change it

    Cloud you please tell me more  or sending me an email =>  u_sagu@hotmail.com

    Thank you