About some features of the ACK in the implementation of the protocol in Gazell or ESB

[hamster66]

In developing the device, for very low battery consumption, I encountered a feature of the implementation Gazell (ESB) protocol. When I send a packet from the DEVICE (PTX) to the HOST (PRX) use the function:

nrf_gzll_add_packet_to_tx_fifo () or nrf_esb_write_payload ()

On HOST device (PRX) get interrupt vector

nrf_gzll_host_rx_data_ready () or nrf_esb_event_handler () 

and send the ACK packet directly from callback function:

nrf_gzll_add_packet_to_tx_fifo () or nrf_esb_write_payload ()

Thus DEVICE (PTX) does not receive the ACK packet immediately. Pack enters the FIFO DEVICE (PTX) and sent to the next processing

nrf_gzll_host_rx_data_ready () (nrf_esb_event_handler ()) →

 nrf_gzll_add_packet_to_tx_fifo () (nrf_esb_write_payload ())

Thus the following is obtained:

#packet from         ACK in FIFO      #recived ACK in       
 DEVICE (PTX)        HOST(PRX)         DEVICE (PTX)
 no                      no               no
 1                       1                no
 2                       2                1 
 3                       3                2
 4                       4                3

So DEVICE (PTX) is forced to send an additional packet to the HOST (PRX) to receive data intended as a response to the previous packet.

Of course, this approach is necessary and important in a constant data stream, but if necessary to save battery life causes extra costs due to the need for additional request from DEVICE (PTX). Please explain - is it possible to somehow send an ACK packet immediately, without waiting for the arrival of the next data from the DEVICE (PTX). Thank you in advance.

[ovrebekk]

Hi

This is a limitation of the ESB and Gazell protocols (as you probably know, Gazell is just a layer on top of ESB).

The ACK payload has to be uploaded before the packet from the PTX is received, otherwise you have to wait for the next packet before the ACK payload is sent.

As you say you would have to send two packets from the PTX if you want the PRX to update the ACK payload based on the data in the first packet.

Best regards
Torbjørn

[hamster66]

Perhaps it makes sense to consider the possibility of cleaning "on the fly" FIFO buffer in the Gazell protocol ? It seems to me such a change would go to the benefit of the protocol and make it more flexible. Now, unfortunately, this can be done only if the protocol is stopped.

bool nrf_gzll_flush_tx_fifo 	( 	uint32_t  	pipe	) 	

Flush the RX FIFO for a specific pipe.

Delete all the packets and free the memory of the TX FIFO for a specific pipe.

Note that it is not allowed to flush a TX FIFO when Gazell is enabled.

The ESB have such an opportunity and it allows you to do interesting things :)

[ovrebekk]

I agree this would be a nice feature. That being said I don't expect a lot of change to the current Gazell libraries. My long term dream is a more flexible Gazell implementation, provided with source code as an add on to the ESB library, but I can't make any promises as to if/when this will happen ;)