The ESB receiver sends problems

[zbxiong]

Hi Q&A My keyboard chip is NRF52832, and the program uses ESB 2.4G communication. The receiver dongle uses NRF52833. Now there is a problem that when the CAPSLOCK is clicked with the keyboard, the receiving dog correctly returns the information of CAPSLOCK. When I click CAPSLOCK with another keyboard at the same time, the receiving dongle cannot return information. My understanding is that when ESB, as the sender, sends out a round of data and waits for a while to receive a response type of data, it will close the reception, and if the time exceeds, it cannot receive data. I don't know if my understanding is correct or how I should solve this problem?

[zbxiong]

Hi Hung Bui
  The problems mentioned above remain.
  1.I can only send the failed returned data to the keyboard to make the indicator light flash.
  2. I want to prevent packet loss by other methods, such as checking whether there is interference        in the current channel. If there is, I will jump to the channel that has been scanned and recorded        as having no interference or very little interference.
  3. But I know what method to use to achieve it. I couldn't find the relevant function for channel              detection.   
 4. Currently, I am using nRF5_SDK_17.1.0_ddde560.

[Hung Bui]

Hi Zbxiong,

1. I don't fully understand what you meant here: ".I can only send the failed returned data to the keyboard to make the indicator light flash." Could you try to explain in more detail ? 
Have you tried to reproduce the issue with our sample ? 
2. As far as I know there is no feature in ESB to do channel survey. It's possible to do channel survey in BLE but it's not implemented in ESB. You will have to think about doing it directly with the radio but then it will break ESB. 
What you can do I think is to implement channel hopping in ESB. It would require the host and the device to keep track of the time and the channel is should jump to. This feature is already implemented in Gazel protocol which is based on top of ESB. This maybe something you can consider. I don't think it would check for channel quality before jumping, it do a scheduled channel hopping but that can reduce the risk of only use one channel all the time. 

But you need to do some calculation to see the rate of packet loss before implementing any measure to improve it.