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.

[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 ;)