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.

RTOS/CC2538: AF_ACK_REQUEST in AF_DataRequest meaning

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

Tool/software: TI-RTOS

Hi,

About using AF_ACK_REQUEST  in AF_DataRequest, I got confused. Please help to see which of  my understanding below is correct (A or B)?  If A, B are both wrong, please correct me !

About Zigbee transmission ackowledgment, there exists "APSC_MAX_FRAME_RETRIES and ASPC_ACK_WAIT_DURATION_POLLED" in f8wConfig.cfg.

(A):

When I use AF_DataRequest (Option: AF_ACK_REQUEST is NOT SET), ZStack will NOT do any acknowledge checking. Data is just transmitted to Antenna and then AF_DataRequest returns SUCCESS.

When I use AF_DataRequest (Option: AF_ACK_REQUEST is SET), ZStack will do acknowledge checking based on APSC_MAX_FRAME_RETRIES and ASPC_ACK_WAIT_DURATION_POLLED. If AF_DataRequest get acknowledgment, it returns SUCCESS and then run AF_DATA_CONFIRM_CMD, Otherwise, AF_DataRequest returns Error. 

(B):

When I use AF_DataRequest (No matter whether the Option AF_ACK_REQUEST is SET or not), ZStack will do acknowledge checking based on APSC_MAX_FRAME_RETRIES and ASPC_ACK_WAIT_DURATION_POLLED. If AF_DataRequest get acknowledgment, it returns SUCCESS, otherwise, it returns Error. The only purpose of setting AF_ACK_REQUEST is that when Zstack got the acknowledgment signal, it runs AF_DATA_CONFIRM_CMD .  

Thank you very much

Bruce Lam

 

  • Z-Stack still does MAC ack no matter AF_ACK_REQUEST is set or not. If AF_ACK_REQUEST is set, the receiver side should do APS ack. If APS ack is not received by sender, APSC_MAX_FRAME_RETRIES and ASPC_ACK_WAIT_DURATION_POLLED will make effect and sender would do APS retry. Once a packet is sent out by calling AF_DataRequest, AF_DataRequest returns success and it is not related to MAC or APS ack.
  • Dear YK,

    OK, I understand . Thank a lot.

    Thank you very much
    Bruce Lam