• State Not Answered
  • Replies 10 replies
  • Subscribers 68 subscribers
  • Views 2989 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 231303
Options
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

aeq

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.

Parents
  • 0 in reply to run_ar

    Hi,

    Thanks for your reply. I read carefully the Backward compatibility section and the whole document, also I checked the sources (nrf_esb.c) from SDK 15.3 but did not find the answer. My question is not about ESB it self I think it's more about the RADIO peripheral. So we set RADIO_SHORTS_READY_START_Msk, RADIO_SHORTS_END_DISABLE_Msk and RADIO_SHORTS_DISABLED_RXEN_Msk on the PTX side. This makes it switch to rx state to receive ack packet as fast as possible after it finishes TX. And this time to switch from tx to rx is (TX disabled) + (RX enabled) + (RX PLL rump up), right? Then on the PRX side we set RADIO_SHORTS_READY_START_Msk, RADIO_SHORTS_END_DISABLE_Msk and RADIO_SHORTS_DISABLED_TXEN_Msk and the time required to switch to TX after RX is (RX disabled) + (TX enabled) + (TX PLL rump up), right? This time values seems to be equal (or the PTX time is even lager), so the PRX may start to tx ack packet faster then the PTX is ready to receive it? Or is there a mechanism in the RADIO peripheral to prevent this situation, maybe some kind of delay when switching between RX and TX to make it for sure longer then TX to RX? I did not find any information on this case in datasheet or online documentation.

    Thanks for any information or explanation on this case.

  • 0 in reply to aeq

    Did you look at the TIFS register?

    Inter Frame Spacing in us

    Inter frame space is the time interval between two consecutive packets. It is defined as the time, in micro seconds, from the end of the last bit of the previous packet to the start of the first bit of the subsequent packet.
  • 0 in reply to run_ar

    Yes, I know about this register. The data sheet says that it is to be used in BLE mode, and any way it is not used in ESB implementation for nrf52 and any other protocol implementation that I saw. The radio seems to be working with a configuration I described above, and what am I interested in is why it works. It seems that there is an additional delay in RX to TX switching with shortcuts. I am looking for a confirmation of this or some description of the radio timings with shortcuts set as I wrote above.

Reply
  • 0 in reply to run_ar

    Yes, I know about this register. The data sheet says that it is to be used in BLE mode, and any way it is not used in ESB implementation for nrf52 and any other protocol implementation that I saw. The radio seems to be working with a configuration I described above, and what am I interested in is why it works. It seems that there is an additional delay in RX to TX switching with shortcuts. I am looking for a confirmation of this or some description of the radio timings with shortcuts set as I wrote above.

Children
Related