This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52833 ESB ACK PAYLOAD and on_radio_disabled_rx_ack

Hi i'm studying ESB in nrf52833 DK

I have a few question.

1. When a packet is sent from ptx to prx, transaction starts, and when prx receives a packet from ptx, it sends an ACK to ptx.
At this time, if there is a packet previously uploaded to prx, it is correct to send ACK + payload, right?
And when ptx receives ack, TX_SUCCESS event is occured and when ack + payload is received, RX_SUCCESS is occured after TX_SUCCESS.
Is the ESB process I understood right?

2.Something strange happens in debugging mode.
When PTX sends the first packet and receives ACK+PAYLOAD from PRX, the packet uploaded in advance to PRX must be received.
However, if hold the break point in debugging mode and proceed, PTX receives the same packet sent by PTX again.
Is it because the timing issue?

3.Last question, what is the role of the on_radio_disabled_rx_ack() function?
Does it play the role of sending ACK + payload uploaded in advance from PRX to PTX?

Parents
  • Hi,

     

    1. When a packet is sent from ptx to prx, transaction starts, and when prx receives a packet from ptx, it sends an ACK to ptx.
    At this time, if there is a packet previously uploaded to prx, it is correct to send ACK + payload, right?
    And when ptx receives ack, TX_SUCCESS event is occured and when ack + payload is received, RX_SUCCESS is occured after TX_SUCCESS.
    Is the ESB process I understood right?

    When .protocol =  NRF_ESB_PROTOCOL_ESB_DPL and .selective_auto_ack = true, you enable the usage of dynamic payload length and ACK payload;

    that is correct.

     

    2.Something strange happens in debugging mode.
    When PTX sends the first packet and receives ACK+PAYLOAD from PRX, the packet uploaded in advance to PRX must be received.
    However, if hold the break point in debugging mode and proceed, PTX receives the same packet sent by PTX again.
    Is it because the timing issue?

     The protocol requires that the Radio IRQ vector is processed by the CPU for each event. If you halt the CPU mid-process, it will not be able to handle the protocol accordingly, and when you start up the CPU again; the timing is off.

    Note that when you halt in debug mode, you only halt the CPU. Other peripherals, like the Radio, PPI, Timers, etc; run normally.

    3.Last question, what is the role of the on_radio_disabled_rx_ack() function?
    Does it play the role of sending ACK + payload uploaded in advance from PRX to PTX?

     When this function executes; you have just sent the ACK payload, and you're going back to receiving on the RX buffer (ie: "normal RX mode").

    The function that sets up the ACK payload is on_radio_disabled_rx

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    1. When a packet is sent from ptx to prx, transaction starts, and when prx receives a packet from ptx, it sends an ACK to ptx.
    At this time, if there is a packet previously uploaded to prx, it is correct to send ACK + payload, right?
    And when ptx receives ack, TX_SUCCESS event is occured and when ack + payload is received, RX_SUCCESS is occured after TX_SUCCESS.
    Is the ESB process I understood right?

    When .protocol =  NRF_ESB_PROTOCOL_ESB_DPL and .selective_auto_ack = true, you enable the usage of dynamic payload length and ACK payload;

    that is correct.

     

    2.Something strange happens in debugging mode.
    When PTX sends the first packet and receives ACK+PAYLOAD from PRX, the packet uploaded in advance to PRX must be received.
    However, if hold the break point in debugging mode and proceed, PTX receives the same packet sent by PTX again.
    Is it because the timing issue?

     The protocol requires that the Radio IRQ vector is processed by the CPU for each event. If you halt the CPU mid-process, it will not be able to handle the protocol accordingly, and when you start up the CPU again; the timing is off.

    Note that when you halt in debug mode, you only halt the CPU. Other peripherals, like the Radio, PPI, Timers, etc; run normally.

    3.Last question, what is the role of the on_radio_disabled_rx_ack() function?
    Does it play the role of sending ACK + payload uploaded in advance from PRX to PTX?

     When this function executes; you have just sent the ACK payload, and you're going back to receiving on the RX buffer (ie: "normal RX mode").

    The function that sets up the ACK payload is on_radio_disabled_rx

     

    Kind regards,

    Håkon

Children
Related