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

APS ack replies slow down after NWK LINK STATUS BCast?

Steve3483
Intellectual 645 points

Other Parts Discussed in Thread: CC2531EMK, Z-STACK

Hi,

I'm using ZStack-CC2530-2.2.0-1.3.0.

I have a simple 2 node test set up with ping server task that runs on a coordinator node and a ping client end device. The end device is powered and it's receiver is always on.

The ping client sends blocks of 1000 pings to the coordinator. It waits for an end-to-end ACK of each ping message before sending the next. I'm sending and getting acknowledgement at a rate of about 30 pings/sec. On the packet sniffer everything looks fine with no retransmissions.

My problem is that after about 4000 pings everything slows down. I can see on the sniffer that the reason is that APS ACK  reply from the coordinator is being delayed by about 300ms.

On the sniffer I can see that the coordinator broadcasts a Network LINK STATUS command (08). The APS ACKs to my ping messages slow slow immediately after this broadcast and never recover.

If I restart the client everything recovers OK and then slows down as before.

The coordinator code couldn't be simpler, any ideas what could be causing the ACK reply to be delayed on the coordinator?

Thanks, Steve.

 

 

 

 

  • 0
    Intellectual 645 points

    Hi,

    nwk_globals.c/line 287:

     // To compile out the Link Status Feature, set NWK_LINK_STATUS_PERIOD
     // to 0 (compiler flag).

    This fixes the APS delay problem.

    I guess NLME_InitLinkStatus() doesn't  work (correctly). Go to the back of the class TI.

     

    Steve.

     

     

  • 0
    TI__Expert 5255 points

    To clarify - the APS ACKS are sent from the Coordinator normally until the very first LINK STATUS broadcast?

  • 0 in reply to xyzzy
    Intellectual 645 points

    Hi,

    Yes, the ack delay prior to LINK STATUS is ~10ms. After the delay it is ~300ms.

    See sniffer screen shot below.

    Steve.

  • 0 in reply to Steve3483
    Intellectual 260 points

    I observe the same behaviour !

    I am using ZStack-CC2530-2.3.0-1.4.0, on a CC2531EMK USB dongle.

    Description of the test: a coordinator sends application data (report commands of Smart Energy attributes) to an end device, which has its receiver always on.

    So, we have:        coord        -->          end device

                               1.         --- app data -->

                               2.         <--   ack   ---

                               3.         <--- app ack --

                               4.          ---- ack--->

                               Then the coordinator restarts sending another frame as fast as possible.

    At first, a typical timing (shown by TI's packet sniffer; see enclosed screenshot and log) is:

    1. -- 1,6ms --> 2. -- 7,6ms --> 3. -- 1,2 ms --> 4. -- 8,9 ms --> 1. and so on.

     

    The problem is that: exactly after the coordinator issues the 4th 'NWK Link Status', the timing from 4. to 1. gets much longer : in the range between 200ms to 400ms (not regular). My code still sends a new frame as fast as possible following step 4.

     

    Disabling the Network Link Status indications (by building with NWK_LINK_STATUS_PERIOD=0) prevents the problem from occuring.

    Building with a shorter value for NWK_LINK_STATUS_PERIOD (exemple: 3) makes the problem occur earlier (still exactly after the 4th NWK Link Status). Note: this was the case in this log ; we have network link status at +3 seconds, +6 seconds, +9 seconds and +12 seconds.

    -- Is there any update on this issue? --

  • 0 in reply to Xavier Boniface
    Intellectual 260 points

    I wrote:

    > I observe the same behaviour !

    > I am using ZStack-CC2530-2.3.0-1.4.0, on a CC2531EMK USB dongle.

    I could see that a new version of Z-Stack was released (v2.3.1.). I'll have to check if the issue is still there with this update. I browsed the release notes though, and I guess nothing was fixed in this area.

    Xavier

  • 0 in reply to Xavier Boniface
    TI__Mastermind 19350 points

    I think that it is fixed on the latest 2.3.1-1.4.0, the more overt problem fixed by the fix was the OAD became very slow, and that was probably the fix mentioned in the release notes since most users are not looking at this detail as you are.