• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 510 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.

Issue with orphaned ZED

Igor Sherer
Guru 31280 points
Other Parts Discussed in Thread: CC2530, Z-STACK, CC2531

Hi All,

 

I have an issue with orphaned ZED. Once I take it away from its parent

(ZC in that case) and bring it closer (10cm) to other router on the network,

I see that ZED sends orphan notification and repeatedly sends beacons but,

it doesn't joins to the new parent. However, if am taking the device back to its

previous parent (the distance is ~5meters), the ZED joins back. What can be

the reason to such a behavior?

 

I'm using Z-Stack 2.4.0 (ZigBee-PRO), the part is cc2530 on a custom board.

The distance between ZC and ZR is ~10meters in office building like area.

The poll rates are managed manually as follows: The ZED switch the poll

rates from off to other intervals once it have some message to send.

After the message sent + few seconds all the poll rates switched back to

off state.

 

I've attached packet sniffer captures (cc2531 dongle): 3034.08.23.2011 - sniffer data.psd

  1. ZED NWK address is 0x182D.
  2. This behavior can bee seen from packet #154 to packet #233

If any one have an idea what is wrong here, please advice how can I fix

this behavior.

 

Edit: 

In my last experiment, I've enabled NWK_AUTO_POLL, and removed

all lines of code where i'm manually setting the poll rates. Now when

ZED goes orphan it rejoins to network (added to a new parent).

 

Thank you in advance,

Igor 

  • 0
    TI__Mastermind 19350 points

    So I don't get what you are asking for as you have answered your own question - the ZED needs poll rates on in order to do a re-join or new join and you've already proved that to yourself.

     

  • 0 in reply to Dirty Harry
    Guru 31280 points

     

    Didn't have the time to write my question. :)

    Q: I'm trying to manage manually the poll rates, I'm enabling and disabling

    it, and it works fine. The problem occurs when ZED goes to orphan state,

    and cannot join to new parent even if I enabling the poll rates, so I'm stuck.

    I know that the experiment proves that poll rates should be enabled (that

    was my first shot), however, what is the suggested pattern for enabled polls?

    Is there any documentation (besides power management)?

     

    Thanks in advance fro any suggestions,

     

    Igor

  • 0 in reply to Igor Sherer
    TI__Mastermind 19350 points

    Ok, so this is what you should be doing:

    1) turn off all poll rates and either PM3 until button press or set a long OSAL timer and PM2 until timer wakeup.

    2) wakeup, turn back on all poll rates, send your message, set a short OSAL timer (say 20-100 msec depending on the depth and activity on your network) in order to receive the message send confirmation and go to step 1).

    3) if you get some bad feedback, leave all poll rates on to allow ZED to find a new parent.

    What are the bad feedback? Check out the code in GenericApp sample application, GenericApp_ProcessEvent()

           case AF_DATA_CONFIRM_CMD:
              // This message is received as a confirmation of a data packet sent.
              // The status is of ZStatus_t type [defined in ZComDef.h]
              // The message fields are defined in AF.h
              afDataConfirm = (afDataConfirm_t *)MSGpkt;
              sentEP = afDataConfirm->endpoint;
              sentStatus = afDataConfirm->hdr.status;
              sentTransID = afDataConfirm->transID;
              (void)sentEP;
              (void)sentTransID;

              // Action taken when confirmation is received.
              if ( sentStatus != ZSuccess )
              {
                // The data wasn't delivered -- Do something
              }
              break;

            case AF_INCOMING_MSG_CMD:
              GenericApp_MessageMSGCB( MSGpkt );
              break;

            case ZDO_STATE_CHANGE:
              GenericApp_NwkState = (devStates_t)(MSGpkt->hdr.status);
              if ( (GenericApp_NwkState == DEV_ZB_COORD)
                  || (GenericApp_NwkState == DEV_ROUTER)
                  || (GenericApp_NwkState == DEV_END_DEVICE) )
              {
                // Start sending "the" message in a regular interval.
                osal_start_timerEx( GenericApp_TaskID,
                                    GENERICAPP_SEND_MSG_EVT,
                                    GENERICAPP_SEND_MSG_TIMEOUT );
              }
              break;

    You see above - data wasn't delivered, do something. This something might even be to reset network state so that ZED is not just trying to re-join its current PanId but opens back up to all of the PanId's if you have -DZDAPP_CONFIG_PAN_ID=0xFFFF in f8wConfig.cfg

    Also, ZDO_STATE_CHANGE and the state is no longer DEV_END_DEVICE - something is bad, don't turn off the poll rates until get a new parent, or stop trying to save some battery power and try again later.

     

  • 0 in reply to Dirty Harry
    Guru 31280 points

    Thanks for your reply. It gave me the idea to decrease the time of the polls. :)

    For now, as it seems, I've solved the problem by setting the "Queued Data Polling"

    and "Response Data Polling" to 100mSec (previously 200mSec).