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

ESB EVENT_RX_RECEIVED on ACK

Hello,

I am trying to establish a bi-directional communication between two nRF52840-DK through ESB protocol. As a first step I am using the ESB example available in the SDK 15.3.0, setting one unit as TX and the other as RX. I expected to be able to catch the ACK message in the event handler of the TX (and get the ACK payload), but debugging the code with a breakpoint in the case NRF_ESBEVENT_RX_RECEIVED, I see that that part of code is never reached. However, TX messages are correct and the case NRF_ESB_EVENT_TX_SUCCESS in the TX side is regularly reached. 

Reading all the ESB documentation I understood that the configuration of the example enables the automatic ACK, so bi-directional communication should be active. Can you please tell me where I am wrong?

Thank you and best regards,

Enrico   

Parents
  • Be aware the payload is attached to the next ack. If you write the payload in the RX_RECEIVED of the Receiver, it will not be sent that packet, but the next.

    Are you using multiple pipes?

    Be aware that the fifo's head pipe will get the payload, and if there are other pipes in the fifo, they'll wait until a message on that pipe comes in to be an ack payload.

    Also, default configuration has a maximum of 32 bytes payload.

    Furthermore, keep the time in the callbacks as short as possible. Set some flags, copy some data, and handle the rest in your main loop.

  • Hi Andre,

    actually I am just testing it using the example available from the SDK 15.3.0 without modifying it. So, just to clarify, I set a breakpoint in this part of the code of the TX but it is never reached:

            case NRF_ESB_EVENT_RX_RECEIVED:
                NRF_LOG_DEBUG("RX RECEIVED EVENT");
                while (nrf_esb_read_rx_payload(&rx_payload) == NRF_SUCCESS)
                {
                    if (rx_payload.length > 0)
                    {
                        NRF_LOG_DEBUG("RX RECEIVED PAYLOAD");
                    }
                }
                break;

    From my understanding, the ACK message should always be sent from the receiver, thus the event in the above code should be raised.

  • Yes, that looks correct.

    The payload is sent if the head if the fifo contains a payload for the pipe a packet is received on. If the head of the fifo is a different pipe, nothing is sent.

    When writing the payload on the receiver, verify it has the correct pipe and length set. Also verify the return code from nrf_esb_write_payload.

    Also, what version of the DK are you using? Do they have the production or engineering samples of the nRF52840? There were some issues with odd number pipes on the Engineering Samples.

Reply
  • Yes, that looks correct.

    The payload is sent if the head if the fifo contains a payload for the pipe a packet is received on. If the head of the fifo is a different pipe, nothing is sent.

    When writing the payload on the receiver, verify it has the correct pipe and length set. Also verify the return code from nrf_esb_write_payload.

    Also, what version of the DK are you using? Do they have the production or engineering samples of the nRF52840? There were some issues with odd number pipes on the Engineering Samples.

Children
  • I have the PCA10056 1.1.0 2019.26 683907503, I am not sure how to understand which type of nRF52840 is on this board. Anyway, I am only using pipe 0 so this should not be a problem.

    I added the following code to the RX in order to write a payload on the receiver:

    nrf_esb_payload_t tx_payload = NRF_ESB_CREATE_PAYLOAD(0, 0x01);
    
    for(uint8_t i = 0; i < PAYLOAD_LENGTH; i++)
    {
        tx_payload.data[i] = i;
    }
    tx_payload.length=32;
    
    if (nrf_esb_write_payload(&tx_payload) == NRF_SUCCESS)
        {
          payload_ok = 100;
        }
    else
        {
            NRF_LOG_WARNING("Sending packet failed");
        }

    Now the ACK payload should be in the queue and sent back to the transmitter when a message is received. Unfortunately, I do not see it in the transmitter yet.

Related