• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 57 subscribers
  • Views 830 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.

CC2652R: maximum poll failure in ZED before triggering rejoin.

Walter Macamos
Genius 5345 points

Part Number: CC2652R
Other Parts Discussed in Thread: Z-STACK

Hi TI Team,

We want to adjust the maximum poll failure in ZED before triggering rejoin.  

Is this the correct definition toedit MAX_POLL_FAILURE_RETRIES?

Regards,

Walter

  • 0
    Guru 735695 points

    Yes, that's correct.

  • 0 in reply to YiKai Chen
    Genius 5345 points

    Hi TI Team

    1. We want to delay the rejoin after poll fail to get the ACK. For this we want to increase the poll data request fo multiple times and to increase the interval between poll data request when there is no ACK from the coordinator.

    2. The main issue we observe is the device keeps rejoining continuously and we are unable to control the device during the rejoin process. We want to make sure that the rejoin process takes place only when the device is sure offline and not just because of some ACK packet lost.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/snifferlog_5F00_mar02_5F00_2020_5F00_datarequest_5F00_fast.7z

  • 0 in reply to Walter Macamos
    TI__Mastermind 35070 points

    Hi,

    Data requests (of the same MAC sequence number) that don't receive a MAC ack are retried soon afterwards (the MAC attempts the data request again, up to MAX_POLL_FAILURE_RETRIES).

    Then after POLL_RATE ms, Z-Stack will try another set of (up to) MAX_POLL_FAILURE_RETRIES data requests; it will retry this up to APSC_MAX_FRAME_RETRIES. If it is still unsuccessful, then the device detects that it has lost its parent, and will try to rejoin after SAMPLEAPP_END_DEVICE_REJOIN_DELAY ms.

    As an example, let's say we have:
    - MAX_POLL_FAILURE_RETRIES == 2
    - APSC_MAX_FRAME_RETRIES == 1
    - POLL_RATE == 3000
    - SAMPLEAPP_END_DEVICE_REJOIN_DELAY == 10000

    Assuming the parent is offline, the ZED will perform the following sequence:

    1. ZED polls, but doesn't receive ack (MAC seq == 11).
    2. ZED immediately polls again (MAC seq == 11), doesn't receive ack.
    3. ZED immediately polls again (MAC seq == 11), doesn't receive ack.
    4. ZED waits 3000 ms, then polls (MAC seq == 12), doesn't receive ack.
    5. ZED immediately polls again (MAC seq == 12), doesn't receive ack.
    6. ZED immediately polls again (MAC seq == 12), doesn't receive ack.
    7. ZED determines that it has lost its parent.
    8. ZED waits 10000 ms, then sends a Beacon Request to find a parent. It repeats this until it finds a parent.

    Please modify the above values to meet your needs for how soon the ZED determines when it has lost its parent.

    For your points:
    1. It seems that you may want to consider increasing APSC_MAX_FRAME_RETRIES and/or POLL_RATE.
    2. Based on your log, it seems that 0x22A2 is sending Data Requests at a reasonable rate (every 1 second). I'm not sure what you mean that you are not able to control it.

    Regards,
    Toby

  • 0 in reply to Toby
    Genius 5345 points

    Hi Ryan,

    Thanks. For our battery powered devices with poll rate is zero, is it normal to see data request?

    Thanks,

    Walter

  • 0 in reply to Walter Macamos
    Guru 735695 points

    If your battery powered device with poll rate zero send a message, it might do an extra polling to get APS ack or to check if there is message on its parent node for it.

  • 0 in reply to YiKai Chen
    Genius 4440 points

    Hi YiKai Chen

    you mean that the battery powered device had a better to wake up 1s or 1min?

    Thanks!

  • 0 in reply to userjiabo
    TI__Mastermind 35070 points

    The time between data polls is specific to your application needs.

    Longer poll period: longer battery life, higher latency.

    Shorter poll period: shorter battery life, lower latency.

  • 0 in reply to userjiabo
    Guru 735695 points

    I mean you have to make your device polling to get APS ack but you have to set polling rate by your according to your use case/scenario.