Role of Zigbee Coordinator

Hi,

the coordinator is responsible for controlling the network. It must absolutly never goes down.

Coordinator should not goes down, so if it happened, it is a failure. But you can imagine to

save the network's parameters on non-volatil memory and reload them after power up. 

For your application, when coordinator starts up it scans for every channels and start a 

network on a channel where there is less activities and on another PanID that them existing.

When there are only end_devices coordinator determines that there is no network for this

channel-PanId, but when there are routers, it starts its network on another channel-PanId.

Launix.

Thanks Launix for the reply.

I do agree that the coordinator should always be powered on. But i would like to look into worst situation too.

Yes, I did store the Channel number and PANID in NV memory. I start the coordinator to form a network with channel no.10 and PANID 74 (I store this Channel no 10 and PANID 74 in NV memory). After network formation, the Coordinator is switched off and switched on while the associated routers and end-deivces are active. Now the Coordinator  goes to Channel 10 and PANID 75.

So can i consider this as a limitation in Zigbee?

If the coordinator goes down in a active network, it can not join to the same network again. All associated routers and end-devices should be restarted again if there is unexpected power failure for coordinator.

Can some one provide me the supportive documents?

Thanks

Skay,

It is not normal to turn off the Coordinator unless of a power failure. I guess this is the scenario you are testing for, right?

1. Have you tested this with a fixed PANID set in the *.cfg file?

2. Have you tested the SOFT START feature?

3. Do you have Security enabled?

LPRF Rocks the World

1. Have you tested this with a fixed PANID set in the *.cfg file?

Yes, we did the change in *.cfg file. FYI, we are using ZASA application for this testing purpose.

The scenario: we have fixed PANID as 74 and Channel 10 in sample_app.cfg file. Coordinator is started with couple of routers and end-devices with Channel 10 and PANID 74.  After few minutes, the Coordinator is powered off and powered on to simulate unforeseen situation of power failure. Now it is expected that coordinator should be active in channel 10 and PANID 74, but it starts with Channel 10 and PANID 75!

It seems something happening at Stack or MAC level?

2. Have you tested the SOFT START feature?

I will be grateful if you can explain on the same?

3. Do you have Security enabled?

I think security is not enabled in ZASA application.

Hi SKay,

This is because the routers is responding with beacons when the coordinator is trying to reform the network. So, the coordinator actually thinks that there is other network in vinicity and will not form the same network again.

What you can do is let the coordinator form other network in some different channel or with other PANID (like you are already doing) and when the routers or end devices noticed that the old network is not formed anymore (for example, when it tried to send a packet and get no response from coord), then you can reset the devices and put all to find the new network and request new association. The new network will be formed quickly and you can re-send the packets that are missed or just send new packets (depending on the application). As you said, this is just for a failure in coord, so it´s a rare event. This is just an example to solve the situation, but you can think in many different ways. Hope this help!

DedsBee

One more observation

zb_ReadConfiguration(ZCD_NV_PANID) gives PANID as 74 while zb_GetDeviceInfo(ZB_INFO_PAN_ID) gives PANID as 75 !!

Thanks DedsBee for your reply. I totally agree with you. I have no doubt that restarting coordinator requires restarting of other router and devices associated with it until i received a clarification mail from a client and marketing team.

I just started to explore further when i got mixed information, some say coordinator can rejoin the network in beacon enabled network! I don't find any premitives for coordinator to rejoin a network in the specification, i might be wrong too.

Is the any significant change in PAN formation between beacon and non-beacon enabled network?

Though there is no specific information available in CC2480 datasheet, i think Z-stack / Zigbee (with respect to zigbee alliance) allow non-beacon network only, is that right?

we have to take care of unforeseen circumtances in real situation and that has to be documented when making a product. Obviously there will be 1000s of devices/routers will be connected to a Coordinator on a decent wide are PAN network, In this case if all of the devices/routers has to be powered up again on failure of the coordinator, it should be big task. It is a limitation in zigbee which has to be documented when making a product.

Awaiting comments.

Skay,

I guess I missed you where using CC2480 and ZASA. However, your statement is interesting when say that the two different API returns a different value for PAN ID. 

After you restarted the coordinator,

1. Did you rewrite the PAN IDwith zb_WriteConfiguration?  (I guess not)

2. What did you use as the ZCD_NV_STARTUP_OPTION after your reset of the Coordinator?

LPRF Rocks the World

1. Did you rewrite the PAN IDwith zb_WriteConfiguration?  (I guess not)

Yes, we have used zb_WriteConfiguration. The PAN ID is written only once after every reset of the device in ZASA application  in Function static void appReset(void) in case case appWaiting.

Update: We also tried without zb_WriteConfiguration, even then it chooses PANID 75!

2. What did you use as the ZCD_NV_STARTUP_OPTION after your reset of the Coordinator?

ZCD_STARTOPT_RESTORE_STATE  is being used, though we have tested with all other options too!! Like ZCD_NV_STARTUP_OPTION,ZCD_STARTOPT_CLEAR_CONFIG, ZCD_STARTOPT_RESTORE_STATE
ZCD_STARTOPT_AUTO_START and with value 0x00 --> as per the section 7.2.2 Scenario 2 of the datasheet "cc2480 Interface Specification.pdf"

Note to Moderator: Can this thread be moved to "Low Power RF Software" topic?

Hi SKay!

Actually you don´t need to power up again all devices in a coordinator failure event. You can do this automatically. As I said, you can write a code that recognize the coordinator failure and just do a network reset, re-sending associations requests.

You can do that in many ways. For example, when a device try to send a packet and get no response from coordinator, this could be a failure. Or you can program your devices to send "trash" to the coordinator in a pre-determined time, just to see if you get a response. This is off course, specific to your application. I agree with you that this is really an important thing to handle in a real situation. I have a big zigbee network that is running with that logic. The end devices and routers send one packet every 10 min to the coordinator. If the coordinator doesn´t reply (coordinator failure or broken link), the devices resets their MAC and starts to find another network that is probably formed by coordinator (after the failure has been corrected) in other channel.

This is a tested procedure that is working well. So the network is reliable even in a coordinator failure event and you don´t need to manually reset all devices (too much work). :)

Off course, here I have relaxed time to send packets (every 10 min) and It´s not critical if I miss some packet so I can even send "trash" to the coordinator that this will not overload the network. Actually I do not need to send "trash", I just take the fact that all devices send packets only to the coordinator. If in your network the end devices or routers need to communicate with each other, so you need to send something to the coordinator to recognize it´s failure. So you need to take account that this could cause too much traffic in your network. Well, as you can see, this is totally dependent to your application. :)

Regards,

DedsBee

Hi DedsBee,

Thanks for your detailed solution. I haven't thought from device/routers perspective to have a solution.

I am sure there should be lots of trails to figure out the power anotomy of the end-device. :)

Thanks again... but i am just curious DedsBee, to find supportive information for this coordinator limitations, as i find people with mixed information. I find most of the discussion on this limitations on coodinator is not properly explained with supportive documents.

Also i wait for the reply from 'LPRF Rocks the World' :)

Hi,

By the way, assume a coordinator failure (shut down and power up), and it forms another network. By software, the routers and end devices take notice of the coordinator failure and decide to restart to join the new network. But what about the bindings on each device? Since they have new short network addresses (given by coordinator), all the bindings are obsolete and must be re-done, no?

What is your opinion?

Regards,

Hi,

We have a feature called NV_RESTORE that would handle the case of a power cycle. 

However, if the device (e.g. coordinator) was damaged
and needed to be replaced, then NV_RESTORE would not help.

Typically you would need to instantiate a new device and recomission the network.

Another idea would be to clone or backup your current coordinator.

LPRF Rocks the World

Hello,

I know the NV_RESTORE option,but this option can't help since, as I wrote, the network address of the routers and end devices are obsolete (the one that reside on the Non Volatile memory) since they join the new network formed by the coordinator (and then, if I'm right, they receive new network address). Unless binding is using the MAC address ???

This point is critical for me.

Regards,

Olivier

With NV_RESTORE, the coordinator does NOT form a NEW network, it just comes back into the network! So all your addresses will be the same, because the coordinator is before the power failure the same as it is after.

If the coordinator is the same as before, there will be no change of your network addresses, therefore your device's network addresses will be correct and working.

Have you tried this feature with your network/coordinator?

Hello,

Do you read the beginning of the post (discussion between SKay and DedsBee) ?

The problem is that it seems that the coordinator CAN'T comes back to an existing network after shut down -> apparently (even with parameter like a fixed PANID stored in Non Volatile memory) at start up, it sniffs to see if the PANID is already used and in this case it increment it's own (the one that is stored in NV) to form a new network. And it is supposed that the Routers and End devices will restart to this new network after some kind of detection.

Then what about the binding informations stored on the routers and End Devices? There are obsolete since each device has a new network address.

This is very important for me since the binding are performed manually during commissioning (push button). If this problem is exact, I have to consider it as a bug in Z-Stack or in the ZigBee specification. Indeed, what can I do when the system is implemented ??? (I can't comes back to a customer each time a electrical shut down has occured).

All the problem are gone if the coordinator can simply rejoin it's formed network, then with the same PANID.

Regards,

It sounds like you need to turn on NV_RESTORE by adding the define somewhere:

Project -> Options -> Compiler -> Defined symbols

f8wConfig.cfg

f8wCoord.cfg

Thanks but It sounds like you have to read all the messages before posting. [:#]

I know the NV_RESTORE option, that's not the problem.

Regards,

Hello -

If NV_RESTORE is not the solution to your problem, then you are not stating your real problem. I read this from you: "...at start up, it sniffs to see if the PANID is already used and in this case it increment it's own ..."

If you compile a ZC (ZigBee Coordinator) with NV_RESTORE and you use it to form a network with at least 1 device and then you cycle power to the ZC, it does not "sniffs to see if the PANID is already used", it just picks up where it left off and it is using the PANID of the network.

Ok Folks, I think that I realize what you are running into with not being able to use "NV_RESTORE" if you are naively using the ZASA - you really must study and fully understand that simple sample Z-Accel master code, at the very, very least, just the sample_app.c. I was advised by monnoliv to read the entire chain, so I advise back - grep for every occurrence of what you are trying to do. In this case, ZCD_NV_STARTUP_OPTION. Look for every occurrence of that and you will see what is happening.

 The first place that you find it is in appJoinFail() where the RFD is setting it "on", so to value ZCD_STARTOPT_RESTORE_STATE

Then you find it in appReset() where you see that all devices set it "off", so to ZCD_STARTOPT_CLEAR_CONFIG. Whoa - warning bells should be going off here - you are asking the Z-Accel slave to clear its NV network configuration and start clean every time that you reset.

Finally, you find ZCD_NV_STARTUP_OPTION in appStart() where, as you read the comment, all devices are turning it "on".

So now you see your dilemma - your last runtime command to the Z-Accel slave is to do NV_RESTORE, but your first powerup command to the Z-Accel is to clear NV. Thus, immediately after powercycle, the Z-Accel slave is working hard to NV_RESTORE until the master comes along and tells it what, stop, CLEAR! ZASA is default to always clear so that beginners don't go crazy when they power on a device and they don't see it go over-the-air (OTA) - they will be writing a very long chain asking why is the device locked-up and refuse to go OTA and find and join a network? Because on previous powerup the device did join  a network and now it just NV_RESTORE. So for your application, you have to figure out how and when your master is going to command the Z-Accel slave to CLEAR and when it will be happy to have a network address and command the Z-Accel to NV_RESTORE. Maybe you can add some code to detect a button press + hold for 10 seconds to CLEAR and otherwise default to restore.

I'm using stack 1.4.3 1.2.1, I found sometimes the coordinator sends boardcast to network when it boot up but sometimes do not. If it sends, existed router will respond beacon to make coordinator change pre-defined PANID to PANID + 1. If coordinator does not send boardcast to network when it boot up, then everything is fine.[:D] it can go back existed network with same PANID!

But I don't know why sometimes sends boardcast and sometimes does not. I found once it doesn't send borardcast it never sends again. You can reboot coordinator in any time without concern rejoining issue.

Dear all,

I'm very glad to share with you the root cause. I'm sure I've got it!

If we flash a coordinator with "Erase flash" option, that means it should erase all memory include NV on the chip. So the new coordinator has NOT any associated devices! So, when it power on, it will send beacon request in the air, if a router (which has the same CHANNEL and PANNID) heard the request, then response a beacon boardcast, that causes the new coordinator change the PANID otherwise it cannot start network.

If a new router or an end device had joined the new coordinator's network once, the coordinator will never send beacon request when it reboot. So, it can go back original network with same PANID.

Happy New Year!

Henry

  In my CC2480 app (not ZASA based) this is not a problem. Turning-off the coordinator causes no communications stop when it returns. End-devices detect when coordinator is off (timeout on periodic communications) and begin the registration and starting (renew binding only if button press on power up) processes on SAME channel and same PANID. When coordinator returns, the network is reformed and all is fine.

Hello,

Finally I did the test myself (1.4.3 stack on cc2430) and It works well. No PB with NV_RESTORE. Sorry for this thread but for several weeks I was not able to verify the problem.

Regards,

On the CC2480 the PAN ID will always increment even when using only ZCD_STARTOPT_AUTO_START (NV_RESTORE).

Jeffrey -

Please clarify the context of your statement, because taken alone, as it is (i.e. out of context), it is not correct.

Thanks.

Dirty Harry asked me to qualify the above statement because lacked context and was incorrect.

I was in the process of writing a long explanation when I realized I may have made a mistake in my testing.

So I retested and I was incorrect.  Just ignore the above post.

The correct use of NV_RESTORE will allow the Coordinator to rejoin the network without changing the Pan ID.

Thanks Dirty Harry for getting me to look at this again.

If the Coordinator does go down for some reason and it is desired to be brought back on-line into the same network, is it a good idea to use NV_RESTORE.

I am not clear what happens in a big network, if for instance the Coordinator and a couple routers go down, but other routers stay up.  If the Coordinator NV_RESTOREs does the sudden absence of some other devices cause any problems?

After pondering the Coordinator using NV Restore I am more specifically wondering the following:

When a Router or EndDevice is powered off is the network automatically aware of this in any way and would a Coordinator powering up later miss out on this information.

I know if an EndDevice leaves and comes back that bindings can be automatically updated.  Can this update happen if a Coordinator is not present, and again if the Coordinator becomes present later will it be automatically updated at that time.

This thread was moved from "Low Power RF Hardware & Tools" to "Low Power RF ZigBee Software & IEEE 802.15.4" category due to its topic.
--moderator

hi,Dirty Harry


I want to know if I use NV_RESTORE option in ZStack1.4.3, what will be restored when
Coordinator rejoin in the previous network

in detail . 3ks.

Hello Joe -

Since NV_RESTORE is not used by the Z-Stack library code, you have access to all of the code that uses it! Simply use the IAR global search (Ctrl+Shift+F) to look for all occurences of NV_RESTORE in the Z-Stack user code.

-Harry

hello,i want to ask you a question about the zigbee coordinator.

i have an idea, when a coordinator failure or dead in a  zigbee network, can we select a router instead of the original coordinator , as a new coordinator to form a network.

another question, i don't know whrther the Zigbee network must have a coordinator and whether the Zigbee network formed in the low level of  protocol stack？  in the application level,can  we  change the network structure?

thanks!

hello,i want to ask you a question about the zigbee coordinator.

i have an idea, when a coordinator failure or dead in a  zigbee network, can we select a router instead of the original coordinator , as a new coordinator to form a network.

another question, i don't know whrther the Zigbee network must have a coordinator and whether the Zigbee network formed in the low level of  protocol stack？  in the application level,can  we  change the network structure?

thank  you very much!

Hi Yulong,

1. Coordinator is unique in Zigbee network. If the coordinator is failure or dead, other routers would keep the zigbee mesh network working. Actually, the coordinator can be turn off after the Zigbee network is formed.

2. What do you mean to change the network structure? It is mostly impossible because the mesh network is manipulated by Z-Stask.

Hi, YiKai.

Thanks for your answers.

We are dong a project now. One coordinator and some routers form a star network. The coordinator and the routers communicate via Zigbee. The routers transmit their data to the coordinator, then the coordinator transmit all the data from the routers to the sever via GPRS. 

This is a basic function above, then we want to enhance the function if possible. In the original system, there is only one coordinator. If the coordinator is failure or dead, the system is  not working, and the server can't receiver the data from the coordinator. we hope even if the coordinator is dead, the system can still work. 

The strategy we adopt is as follows. If the original coordinator is dead, we select a router as a new coordinator. we hope that the router(new coordinator) can work like a coordinator, then receiver the data from other routers via Zigbee and transmit the data to the sever via GPRS. Our goal is to achieve a polling function.

But I can not confirm whether the idea is feasible from the view of Zigbee principles. we can only call the function in the application level and cannot change the code below the application level.

Thanks.

In you case, I would suggest you to choose one of your routers as a backup receiver, which means all of other routers also report data to this backup router. Then, you can ask the backup router to report to your server when coordinator is failure or dead.

Thanks!

we can not form a network if the coordinator is failure. In our system the routers can not communicate each other, and the routers only communicate to the coordinator. The routers in our system is a end-device actually.

Sorry, I can not explain my idea clearly last time. Our idea is as follows. When the coordinator is dead, we select a router as a coordinator. The router is like a coordinator and form the network with other routers. Then when the new coordinator(the selected router) is dead, we select another router as a coordinator, and ...

I don't know whether this scheme is feasible. When the coordinator is dead, whether the router can form a network with other routers.

Hi Yulong,
I don't think this will work. The problem is that how your routers know if coordinator is failure, dead, or temporary unavailable? 

YK

Hi, YK

The coordinator send beacons to routers for synchronization before the routers send data to coordinator. If the router cannot receive the beacon, then it knows the coordinator failed.

Yulong

This judgment is dangerous. Sometimes, it can't receive the beacon just because of interference. If you can figure out a rule to judge coordinator failure. Maybe you can let all of your routers doing reset and try to join new coordinator.