• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 1936 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 Zibgee mesh network connection issues

Jamaal_Charles
Genius 3245 points
Other Parts Discussed in Thread: Z-STACK, CC2530

Hello,

We are using the CC2530.  We are using Z-stack and IAR.  We have things working fairly well, but there are a couple scenarios we still can't figure out.  

1. If a Coordinator is not present or out of range when an endpoint is powered up, sends an event message or polls for data it goes into an Orphan state and constantly sends a beacon message that results in a high power state drawing almost 30mA continuously. If the coordinator comes on line or the end point comes back into range of the coordinator or router it reconnects and operates at a nominal current state (~10uA). My concern here is that our battery will only last a few hours at this increased rate. We were able to find code to disable the data polling interval so that it won't wake up to receive messages so we won't enter this state if we aren't meaning to send a message, We did this by setting the Data poll value in the f8 config file to 0. We found code that disables beacon messages from being sent after an orphan message is sent but we can't ever get the end point out of the orphan state, if we delay the beacon rate it still stays in the high current state in-between beacons. I'm sure others have dealt with this but we can't find the solution on e2e. I'm thinking there is a solution that will allow the unit to enter a Orphaned state, send a few beacon requests and then sleep for a period (several minutes) (10uA) wake up, try a few more times and then go back to sleep and try this indefinitely until the unit is back in range.   

 

2. If the Coordinator USB is inadvertently shut down (unplugged, computer powered off) when it comes back online the routers and end points won't communicate with it. I have to unplug and replug in all the routers to get it to work again. I'm not exactly sure what is going on here? This is a huge issue because we plan on having deployment of 10+ routers connected to the Coordinator and if for some reason the Coordinator goes down or the homes power goes out when it comes back online they have to go around and unplug all the routers it would be problematic. We've searched e2e and can't seem to find anything. We've found a few threads about setting a compiler setting to force the coordinator to maintain route state after a power cycle but I don't notice any difference so i don't think this the problem or I'm doing it incorrectly.

Any help would be appreciated.

Thank you

  • 0
    Guru 735695 points
    1. If you use Z-Stack Home 1.2.2a, you can find the following defines that allow you to change beacon request duration.

    /* Rejoin retry backoff silent period timer duration in milliseconds - default 15 minutes according to HA test spec */
    -DREJOIN_BACKOFF=900000

    /* Rejoin retry backoff scan timer duration in milliseconds - default 15 minutes according to HA test spec */
    -DREJOIN_SCAN=900000

    2. Do you enable NV_RESOTRE on your Zigbee coordinator, router, and end device?
  • 0 in reply to YiKai Chen
    Genius 3245 points
    Thank you YK,

    1. The zstack code base we are utilizing is the "Z-Stack Mesh 1.0.0" and I do not see those variables to hold off the rejoin beacons. Maybe the Mesh codes calls them something different.

    2. When I use the NV_Restore my Coordinator only works after initial programming and device connections, it sends out the heartbeat messages to all the devices allowing them to join. After I unplug it and plug it back in it never connects to anything again even the end points and routers we had connected prior to the power down. It doesn't even send out a heartbeat anymore.

    I also tried NV_INIT and NV_RESTORE and it resulted in the part never connecting to anything, for both the Coordinator and Router.

    When I leave both NV_RESTORE and NV_INIT out I get the desired function and can see the end points communicating with either the coordinator or router but when I unplug the coordinator the endpoint changes it's destination address to the router it is connected to (not 0x0000) and communicates with that and the coordinator comes back on and sends messages out but both the router and endpoint ignore it. It is almost like the router takes responsibility as the coordinator even though it doesn't have address 0x0000. This is why power cycling all the routers works because it forces them to rejoin with the coordinator.

    I'm viewing all this via the TI packet sniffer dongle

    Thank you
  • 0 in reply to Jamaal_Charles
    Guru 735695 points
    1. Z-Stack Mesh doesn't have backoff capability. However, you can refer to Z-Stack Home 1.2.2a and porting it to your Z-Stack mesh.
    2. If you enable NV_RESTORE and turning off coordinator/turning on it, router and end device should be able to communicate with coordinator.
  • 0 in reply to YiKai Chen
    Genius 3245 points

    Thank you for the quick responses.

    Does TI have any plans for a Mesh 1.0.0 update in the near future? Or, if you could advise on the best way to implement hold back into Mesh. The home code is very different and with my limited time looking at it there does not appear to be a straight forward way to use its hold back code in the mesh.

    Are these issues inherent to Zigbee?  Should we considering migrating to Thread?  Is TI going to offer a Thread stack for the CC2530 (or CC26xxx) in the near future?

    Also, the NV_RESTORE flat out does not work for the coordinator mode, there is something getting set that is making it useless after the initial power cycle. Per my comments above knowing what that might be is currently beyond me at this point.

    Thank you

  • 0 in reply to Jamaal_Charles
    Guru 735695 points

    1. I don't hear that TI has plan to do it in Mesh 1.0.0. You can only study how it is done in Z-Stack Home 1.2.2a and do it by yourself in Z-Stack Mesh.

    2. I know TI would support OpenThraed which you can refer to the discussions in

    3. I just test with my CC2530DK on Z-Stack Mesh 1.0.0 with NV_RESTORE and I see it works fine. I would suggest you to remove and reinstall your Z-Stack Mesh 1.0.0 to test again.

  • 0 in reply to YiKai Chen
    Genius 3245 points

    Thank you so much,

    This was very helpful.  It is working much better now.  One more question... 

    The Z-Stack Home 1.2.2a increased the PollRate variable from 16bits to 32bits allowing the user to set the data poll rate greater than 65seconds. But the NLME_SetPollRate(zgPollRate) function for Mesh is still 16bits. The only definition that exists for the NLME_SetPollRate is in the NLMEDE.h file, there is no NLMEDE.c file that has the function code. I updated the .h file to NLME_SetPollRate( uint32 newRate ); and as expected I got the following warnings.

     

    Warning[w6]: Type conflict for external/entry "NLME_SetPollRate", in module ZDApp against external/entry in module nwk; function types differ in parameter 1; 

    Warning[w6]: Type conflict for external/entry "zgPollRate", in module nwk against external/entry in module ZGlobals; different basic types 

     

    My question is what and where is the binary library file that has this function defined so I can copy it from the Home 1.2.2a into my Mesh area.

    Thank you

  • 0 in reply to Jamaal_Charles
    Guru 735695 points
    There are lots of differences between Z-Stack mesh 1.0.0 and Z-Stack Home l1.2.2a ibrary so you cannot grab Z-Stack home 1.2.2a library to put it into Z-Stack Mesh 1.0.0 directly.