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

Network continuity for power cycles.

rico7362
Prodigy 30 points

Can anybody help?

I am trying to use the cc2480 in an application using the ez430 modules until boards using the same design come in. I have 2 issues that are taking a lot of time to sort. Normally a network can be started with the coordinator and some end points using app acknowledges which require an exchange of 8 packets when data is being sent from the end point. If the power to the coordinator is cycled then when the network is expected to be restarted (confirm from chip) when a report is sent by the end point to the coordinator the coordinator immediately tries to app ack the data a number of times before the end point sends in a data request to the coordinator for the app ack approx 100mS later. The end point does the retries but the process repeats. It seems to be some type of startup sync issue in the coordinator.

The second issue is to do with the cycling of the power on the end point where the end point does a beacon request and the coordinator responds with accepting association requests but the end point does not pick up on it and keeps doing the beacon request. If the end point was to reassociate with the coordinator would it get the same short id or would it be different. Based on looking at some of the other posts it appears that the short address may change and bring the requirement for the application layer to keep track of the 64 bit addresses and hence require the exchange of these at the application level. Any comments here?

In the application it would  be expected that the coordinator power may get cycled for many reasons that are not related to the rf. Also for battery replacement the end point power will be cycled.

Thanks.

  • 0
    Intellectual 535 points

    I can't really help, but I am working through somewhat similar issues right now.

    swra176.pdf states that an EndPoint may pick up a different short address when it rejoins the network.  I think it definitely gets a new address if it joins to a different router.  I would like clarification of this also.

    I am currently playing around with cycling power with the Coordinator and Routers.  I am not dealing with EndDevices right now.

    I can cycle power on a Router and get it to rejoin with the Coordinator.

    However, if I cycle power on the Coordinator, then the Router is no longer able to communicate with the Coordinator, unless I then cycle the power on the Coordinator also.

    It seems that if the Coordinator issues a new ZB_START_REQUEST, then the routers need to start a new ZB_START_REQUEST.  I don't think the order that these are initiated matter.

    I don't know if there is anyway that the Coordinator can tell the Routers to start a new ZB_START_REQUEST, perhaps through a broadcast message?

    The Router does not get any indication that the Coordinator has been powered down.

    Perhaps if acknowledges are used, then the Router could act on a lack of acknowledge.

  • 0 in reply to JeffreyBritton
    Prodigy 30 points

    Thanks Jeffrey,

    My understanding is that the start request (sapi) starts a new network from scratch because it restores the defaults to the network configuration. When resetting the cc2480 with just the autostart option set i believe the previous network is meant to restore, and the endpoints are getting a response from the coordinator. However the coordinator behaves as if the end point will see the app ack when it sends it immediately but the end point is not seeing it and expects to poll for the ack 100mS later. This is the issue with the coordinator. I think when you are cycling the power in your experiments you are forming the network again from scratch each time.

    I am hoping to have the commisioning procedure allow the joining and binding to be controlled by the installer during installation and the network needs to be able to repair itself in the event of glitch's etc. From a security point of view also to stop miscellaneous end points joining the nerwork (and potentially using up the cc2480 resources), the joining to the network needs to be controlled. The rejoining issue getting the new network short address means that the commisioning procedure needs to not depend on the network short address in managing the network as these may change. However when cluster messaging is sent the resolution of which end point sends the data is the short address. Therefore the application layer needs to be aware of the long address to short address associations that we thought the cc2480 was looking after. It may mean that the end points need to alert the coordinator (at the application layer) that a power fail happened or that it has found its assigned network address has changed from a previous address.

    I am getting mixed results with cycling the power on the end points, primarily because of not keeping adquet version control on the changes I make. As usual in software it seems that I am nearly there and the next change will fix the problem but alas it does not (I am still hoping). I feel that I had it working correctly before but not sure what broke it, it may be something to do with the stored pan id but not sure.

    The coordinator issue is the easiest to reproduce and seems that I am overlooking something small but significant, reading the interface spec and developers guide does not offer the solution yet.