This blog is to describe more about the proprietary radio protocol on the nRF52 series. On the Nordic nRF5 SDK, it has two difference protocols.

1. Enhanced ShockBurst (ESB)
2. Gazell

In this blog, I would mainly focus on the ESB because it provides full source code instead of library.

Also, it can do much more flexible to meet some difference users scenarios.

Enhanced ShockBurst 

This user guide describes what Enhanced ShockBurst (ESB) is and how to use it with an nRF5 Series device.

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/esb_users_guide.html

Enhanced ShockBurst (ESB) is a basic protocol supporting two-way data packet communication including packet buffering, packet acknowledgment, and automatic retransmission of lost packets. ESB provides radio communication with low power consumption, and the implementation is small in code size and easy to use.

The ESB protocol was embedded in hardware in the legacy nRF24L Series. The Enhanced ShockBurst module enables an nRF5 Series device to communicate with an nRF5 or nRF24L Series device using the ESB protocol.

ESB features automatic packet transaction handling for easy implementation of a reliable bidirectional data link. A transaction is a packet exchange between two transceivers, with one transceiver acting as the Primary Receiver (PRX) and the other transceiver acting as the Primary Transmitter (PTX).

Features

• Supports a star network topology with typically one Primary Receiver (PRX) and up to 8 Primary Transmitters (PTX)
• 1 to 32 bytes dynamic payload length in legacy mode
• 1 to 252 bytes static payload length between nRF5 Series devices
• Bidirectional data transfer between each PTX and the PRX
• Packet acknowledgment and automatic packet retransmission functionality
• Individual TX and RX FIFOs for every pipe
• Backward compatible with legacy nRF24Lxx Enhanced ShockBurst

Packet transaction

An Enhanced ShockBurst packet transaction is initiated by a packet transmission from the PTX and successfully completed when the PTX has received an acknowledgment packet (ACK packet) from the PRX.

To enable a bidirectional data link, the PRX is allowed to attach a data payload to the ACK packet. To do so, the PRX adds a packet to its TX FIFO, which is sent as the payload in the next ACK packet.

If the PTX does not receive the ACK after the initial transmitted packet, it attempts to retransmit the packet until the ACK is finally being received. The maximum number of allowed retransmission attempts and the delay between each attempt is specified by the most recent call to either nrf_esb_init (where the values of nrf_esb_config_t::retransmit_count and nrf_esb_config_t::retransmit_delay in the nrf_esb_config_t structure specify the number of retransmission attempts and the delay between them, respectively) or the functions nrf_esb_set_retransmit_count and nrf_esb_set_retransmit_delay. The retransmission delay is defined as the duration between the start of each transmission attempt. Note that this differs from the legacy nRF24L Series hardware implementation, where the delay was defined as the duration from the end of a packet transmission until the start of the retransmission.

If the ACK packet sent from the PRX to the PTX is lost, but both the initial packet and the subsequent retransmission attempts are being successfully received by the PRX, the repeated packets will be discarded by the PRX. This prevents the PRX application from receiving duplicate packets. However, repeated packets will always be ACKed by the PRX, even though they are being discarded.

A PTX can select that individual packets that are transmitted to the PRX do not require an ACK to be sent in return from the PRX. This decision is taken by the application when uploading a packet to the TX FIFO using the nrf_esb_payload_t::noack field of the p_payload parameter that is passed to the nrf_esb_write_payload function.

When the PRX receives a packet that does not require an ACK, it does not send an ACK packet to the PTX, and as a result the PTX will continue retransmitting the packet until the maximum number of allowed retransmission attempts is reached.