• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 56 subscribers
  • Views 1176 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.

Cannot receive acknowledge from Coordinator after a successful orphan rejoin

John Xu
Prodigy 220 points
Other Parts Discussed in Thread: CC2530

Hi All,

I really appreciate any help on this!  I have been looking into it quite a while now, but I cannot figure out what is going on.

Here is my setup: 1  Coordinator, 1 router, and 1 end device.

Here are the steps to reproduce the problem:

1.  Coordinator forms network.

2.  Initially, router and end device joins network and Coordinator is the parent of each device.

3.  End device will send a data request to Coordinator every 15 seconds.

4.  Now, turn off Coordinator to simulate a case that end device is out of range.

5.  When end device try to send a data request to Coordinator, it fails and goes into orphan scan.

6.  During orphan scan, end device finds the router as its new parent.

7.  After end device finds its new parent, turn on Coordinator.   Now, strange problem shows up：  End device never receives acknowledge from Coordinator for the data request.  Here is what happens:

         1)  End Device sends the data request.

         2)  I can see Coordinator receives the request but End Device does not receives acknowledge from Coordinator (AF_DATA_CONFIRM_CMD is not received).

         3)  15 seconds later, after End Device sends another request, it receives failure (AF_DATA_CONFIRM_CMD） for previous request.

         4)  The above steps keep repeating....

The problem will go away once I reboot the end device...

Can anybody provide some insights?

Thanks

John

  • 0
    Prodigy 220 points

    When AF_DATA_CONFIRM_CMD is received, the status is 0xb7, which is ZApsNoAck.  But I do see that Coordinator sends the Ack...

    In addition, I also noticed that after orphan scan and find a new parent, the short address does not change on the end device..

    Can anybody help?

  • 0 in reply to John Xu
    Prodigy 220 points

    At this point, I am really lost and need some help.

    After further experiment with the setup, here is what I found:

    1.  After Orphan Scan, ZED did find the new parent - ROUTER while Cooridnator remains powered off.

    2.  If I do not power on Coorinator, but turn off/on ZED, it goes back into Orphan state even though it had successfully find its new parent ROUTER.  However, the network state quickly changes to END_DEVICE with parent to be ROUTER.

    3.  Now if I power on Coordinator, the request that was sent by ZED every 15 seconds still does not get Acked by Coordinator  even though Coordinator receives it...

    4.  The most strange thing is that:

            1.  Power off Coordinator.

            2. After ZED successfully complete an orphan scan and found the new parent -ROUTER, power off ZED as well.

            3.  Power on Cooridnator

            4.  Power on ZED and it goes back to choose Coordinator as its parent, even though it found Router as its parent after previous orphan scan..  And this is the only way

                 that ZED can get Ack from Cooridnator for the data request it sends every 15 seconds...

            5.  However, again, if I do not power on Cooridnator, if I power on/off ZED, it always goes into Orphan state first disregard it has found new parent before....

    Can anybody please help?

     

           

  • 0 in reply to John Xu
    Prodigy 220 points

    Well, I finally figured it out.  The problem is caused by that Coordinator (Parent) does not remove ZED (child) from its association table after it reboots.

    I would think the following method should be how it works， but looks like it is not the implementation in the ZStack:

    • Parent receives a message from ZED that is in its association table (child).
    • It will then check the MAC source address.
    • If the MAC source is not child's short address in the table, then it removes the ZED from its association table (leave). 

            Because ZED always sends message to its parent.  If the message comes from a router (MAC source is different from NWK source), then the ZED must change the parent already.

  • 0 in reply to John Xu
    Expert 1120 points

    Hi,

    I have an identical problem, where I power-down my ZC and my ZED becomes orphan and joins a ZR. Then I power-up the ZC and it receives messages from the ZED (via the ZR) but can't send a response message.

    My ZC gets error 0xF0 (ZMacTransactionExpired ???) in the AF_DATA_CONFIRM_CMD event.

    CC2530, ZStack 2.5.1

    Any solution?

    Thanks, Rami

  • 0 in reply to rami rosenbaum
    Guru 735685 points

    Hi Rami,

    You can refer to http://e2e.ti.com/support/low_power_rf/f/158/p/322914/1123979.aspx#1123979

  • 0 in reply to YiKai Chen
    Expert 1120 points

    Thanks YiKai - as the youngsters say "respec"!

    I followed that post to: http://e2e.ti.com/support/low_power_rf/f/158/p/248017/869835.aspx#869835

    I started with adding the AF_ACK_REQUEST option to my AF_DataRequest() calls, in my ZEDs, for testing the APS ACK, and restarting the ZStack, but that meant loosing the sent message and lots of overhead.

    Yours is a much more elegant solution, probably the correct solution.