Bitcloud parent loss, rejoin delay

[danergo]

Hi!

If I have a Coordinator (C) and a Router (R). and R has a short power outage, it needs about 90 seconds to reconnect to the coordinator. I'd like to know if this is by design, or it can be reduced to somewhere 15-20 seconds?

I'm having the following code snippet for forming and joining to the network:

Code: [Select]

  NWK_JoinControl_t joinControl = {
    .method = NWK_JOIN_BY_DEFAULT,
    .secured = true,
    .discoverNetworks = true,
    .annce = true
  };
  CS_WriteParameter(CS_JOIN_CONTROL_ID, &joinControl);

  //Starting network (results in joining to or forming a ZigBee network)
  zdoStartReq.ZDO_StartNetworkConf = appZdoStartNetworkConf; //Setting the callback function
  ZDO_StartNetworkReq(&zdoStartReq); //Sending a request to the stack
It looks like 90 seconds is defined somewhere, because it's very accurate from 10 times, 7-8 times right after 90 seconds after power outage, the router rejoins.

And another question is what should happen if R's parent (okay, there is no such thing, but anyway) gets a power outage? In this particular case C.
Which callback function should be called in this case by the framework?

So, to summarize, I have 2 questions:

• How can I reduce the reconnection time from R->C when R gets a power outage? Now it's 90 seconds.
• How can I force R to reset itself when it losts it's connection to C due to a power outage in C? Now nothing seems getting called.

Thank you,
danergo

[ataradov]

It looks like 90 seconds is defined somewhere, because it's very accurate from 10 times, 7-8 times right after 90 seconds after power outage, the router rejoins.

There is no specific define for this. This is probably a side effect of some other settings. A few things to try:
1. Don't do anything to CS_JOIN_CONTROL_ID. Under normal conditions there is no reason to modify it.
2. It is highly likely that appZdoStartNetworkConf() is called multiple times with a failure status code. See what this code is.

Which callback function should be called in this case by the framework?

None. As you've said, they don't have a relationship as far as stack concerned. If you want to detect a loss of a specific device, you need to poll it periodically.

[danergo]

ataradov,
Thank you.

My first question got obsolete because I just forgot to enable PDS. With PDS, R "rejoins" to C in 1 second which is far beyond my expectations. 

As for the second one: R should ping C (it's not a particular node, it's always C which is interesting) periodically, to see if it's still there or not, right?
So, the stack won't know that it lost the route to C unless it tries to send some dummy message to C?
What would be a reasonable interval for this dummy message? 1 minute is okay?

Thank you

[ataradov]

My first question got obsolete because I just forgot to enable PDS. With PDS, R "rejoins" to C in 1 second which is far beyond my expectations. 

With PDS there is not really a rejoin, device simply recovers its saved state.

As for the second one: R should ping C (it's not a particular node, it's always C which is interesting) periodically, to see if it's still there or not, right?

Correct.

So, the stack won't know that it lost the route to C unless it tries to send some dummy message to C?
What would be a reasonable interval for this dummy message? 1 minute is okay?

You won't be relying on actual routing tables and all that stack stuff. Your ping message must request an ACK. If no ACK follows, device is lost. Depending on your application you may want to implement some number of retries.

The time interval is not important really. It should be on the order of required detection time. But for small networks you can do it even faster than a minute if you want to.

Edit: It also does not have to be a custom message. You can also use a standard ZDP request that is sent as a unicast. Smart Energy profile, for example uses IEEE Address Request as a ping message.