This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Radio timing nrf24l01+ and nrf52832

Hi, I have an interesting problem with RADIO peripheral. I am trying to achieve the stable
communication between nrf24l01+ and nrf52832, and I have it partially running.
I am using a simple ESB like code for that purpose. So my setup is as follows nrf24l01
operates in esb mode with 1 retransmit and 4 ms ack timeout, nrf52832 is in rx state with
RADIO_SHORTS_READY_START_Msk, RADIO_SHORTS_END_DISABLE_Msk and  ADIO_SHORTS_DISABLED_TXEN_Msk.
The radio disabled interrupt is enabled NRF_RADIO->INTENSET = RADIO_INTENSET_DISABLED_Msk;
In this interrupt I check the CRCSTATUS reg to know when a valid packet is received.
And if it is received I update the NRF_RADIO->PACKETPTR with a constant static payload
buffer as an ack packet. At first it seemed to me that this approach is fine and I was
Able to receive a packet on nrf52 as well as get the ack packet on nrf24, but then I noticed
that some times I receive an empty ack packet on nrf24 but with a correct length.
I think that this might happen because of the time that is required for nrf24l01p to switch
from tx to rx is longer then the time that is required for nrf52832 to switch from rx to tx.
I checked the datasheet and found out that the time required to switch from tx to rx seems to
be indeed higher because of tTXDISABLE is larger then tRXDISABLE while the rump up time seems
to be equal. I also found two undocumented values tRXCHAIN and tTXCHAIN. Are this values somehow
connected with this case? By the way I looked in to the nrf_esb.c in SDK 15.2 and saw that it
behave in a similar way. So to sum up my long question: how does the ptx radio is able to
receive ack packet in time if it requires a longer time to switch to rx then the time required
to switch to tx for the ptx radio? And how is it affected by crystal accuracy?

Sorry for such a long question.

Related