• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 303 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.

ZC re-joining its own network

Anders Jensen
Prodigy 210 points

Hi,

I have a system consisting of one ZC, one ZR and one ZED. My problem is that if the system is up and running, then the ZC is turned off and later turned on, then the ZC doesn't (re)join the network. When the ZC starts, it broadcasts a "Beacon Request" and the ZR replies with a Beacon response. Apparently that makes the ZC think that there already exists a network with that PAN ID (I use fixed PAN ID), and the ZC reports a "Network Startup Failure" to the application and stops. The Beacon response from the ZR does (correctly) indicate that the ZR isn't a PAN coordinator itself. Does anybody know what the correct scenario would be? I mean, is it the ZC or ZR that does something wrong in this situation since it doesn't "simply work"?

  • 0
    TI__Expert 5255 points

    Hi Anders,

    If you compile your ZC with the NV_RESTORE option it will "remember" the PANID so that when it resets it won't try to start a new network -- you won't see the Beacon Request, indicating that it just restarted with the previous network settings. In general, if you need your devices to "remember" their network information after a reset, they should be compiled with NV_RESTORE enabled.

  • 0 in reply to xyzzy
    Prodigy 210 points

    Hi xyzzy,

     

    Thanks a lot for your reply. Well, unfortunately my ZC isn't ZStack based. It is a preprogrammed USB dongle from Silabs - and Silabs provide no support on that product whatsoever. So there is no way for me to modify its behavior. So what I really need to know is the correct scenario when a ZC starts up. The "old" network might or might not still be present. So it needs to work either way. I need to know if the error is in the ZC or in the ZR. A workaround - I guess - would be to make the ZR poll the ZC to see if it is there, and if the ZC disappears, the ZR must reset it's stack so that it doesn't reply on the Beacon Request. Any comments on that solution?