ESB ACK packet not received?

[Philip]

Hi.

I am experimenting with using a nRF52832 to communicate with a nRF24L01+. It is almost working, the nRF52 is sending a packed to the nRF24 ok, and the NRF_ESB_EVENT_TX_SUCCESS event is triggered when the device is in range, so it must be at least detecting the ACK packet back to know the message got through ok. If I turn the nRF24 off (which is setup as RX) then the NRF_ESB_EVENT_TX_FAILED event is triggered instead.

However I am struggling to get the NRF_ESB_EVENT_RX_RECEIVED: event to trigger so I can read the ACK packet.

Basically my question is what will cause the NRF_ESB_EVENT_RX_RECEIVED event to trigger rather than the NRF_ESB_EVENT_TX_SUCCESS? Will it only be triggered when in RX mode, and not by an ACK packet. If so where would I read this ACK payload?

Thanks

void nrf_esb_event_handler(nrf_esb_evt_t const * p_event)
{
    nrf_gpio_pin_set(LED_3);
    nrf_gpio_pin_set(LED_4);
    switch (p_event->evt_id)
    {
        case NRF_ESB_EVENT_TX_SUCCESS:
            nrf_gpio_pin_clear(LED_4); //turn on LED
            
            //NRF_LOG_DEBUG("TX SUCCESS EVENT");
            break;
        case NRF_ESB_EVENT_TX_FAILED:
            nrf_gpio_pin_clear(LED_3); //turn on LED
            //NRF_LOG_DEBUG("TX FAILED EVENT");
            (void) nrf_esb_flush_tx();
            (void) nrf_esb_start_tx();
            
            break;
        case NRF_ESB_EVENT_RX_RECEIVED:
            
            //NRF_LOG_DEBUG("RX RECEIVED EVENT");
            while (nrf_esb_read_rx_payload(&rx_payload) == NRF_SUCCESS)
            {
                nrf_gpio_pin_clear(LED_2);
                if (rx_payload.length > 0)
                {
                
                    //NRF_LOG_DEBUG("RX RECEIVED PAYLOAD");
                }
            }
            break;
        
    }
    NRF_GPIO->OUTCLR = 0xFUL << 12;
    NRF_GPIO->OUTSET = (p_event->tx_attempts & 0x0F) << 12;
}

[Philip]

I have just found a few similar cases that suggest a data packed can only be received with the ACK if the protocol is NRF_ESB_PROTOCOL_ESB_DPL rather than NRF_ESB_PROTOCOL_ESB i.e. dynamic payload is on.

So does this mean a legacy nRF24L01+ system set up to use static payloads and as a RX, can't communicate back via ACK to a nRF52832 setup as a TX? 

Thanks

[Håkon Alseth]

Hi,

 

If your nRF24L radio is configured with static length (and thus; no , you should configure nrf_esb with mode NRF_ESB_PROTOCOL_ESB.

How is your nRF24L radio configured, and how are you setting up the nrf_esb?

 

Are you actually sending an ACK payload from the nRF24L side? If so, then you have to enable the EN_ACK_PAY (and thus the dynamic payload lengths).

 

Best regards,

Håkon

[Philip]

Hi Håkon, thanks for getting back to me.

The nRF24L which is in RX mode is configured with ACK enabled, dynamic payload disabled, and 32 bytes are written to the ACK payload to send i.e. max allowed. It is definitely sending an ACK, as we get two way comms with our other legacy kit (what we are trying to replicate with the nRF52832).

The nRF24L is setup as a legacy system so I haven't changed any settings, and it communicates with other nRF24L set up as TX's ok. 

On the nRF24L you don't need to enable dynamic payload length to be able to send ACKs. We are very familiar with those modules. You just setup the expected payload size on the nRF24L you setup as the TX.

Ideally we want to be able to read the ACK payload on the nRF52832 without havn't to change any settings on the old legacy nRF24L.

Best Regards

Phil

[Håkon Alseth]

If I understand correctly, then this is a very unusual configuration.

You have DPL=0, but EN_ACK_PAY=1. For this to work, you always have to send the static payload length (32 bytes) back to the transmitter in the ACK. Could you please confirm your configuration?

[Philip]

Yes we always send 32 bytes back to the transmitter in the ACK. We write 0x00 bytes to pad out to 32 bytes if we don't have 32 bytes to send.

In hindsight using dynamic payload would have been good, but this is now a legacy system so would be good to be able to communicate with it using a nRF52...

Thanks