• State Verified Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 2040 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 307384
Options

NRF52840 to NRF24L01+ communication with Static Payloads

TMRh20

I have created a library for Arduino to enable NRF52840 <-> NRF24L01+ communication and have most of the functionality working, except for static payloads. Essentially, I've created a library that mimics the ESB protocol from NRF24L01+ on NRF52 devices.

I found that when using Static Payloads on the NRF24L01+, when transmitting from NRF52, I have to disable CRC checking in order to correctly receive the ACK packet, else I get a CRC error that I can't explain, because the ACK comes from a working nrf24L01+ module.

The other way around, transmitting from NRF24, I receive the initial packet, but am unable to get an ACK packet back to the transmitting device from the NRF52.

I am wondering:

A: Is disabling CRC checking before receiving an ACK while using static payloads correct behaviour? I don't see why CRC checking would be necessary on static ACK packet.

B: How to get receiving working? There has to be something I'm missing, but what? I've tried disabling CRC before sending the ACK, but no luck there.

Everything works well with Dynamic Payloads enabled btw.

I've been stuck on this issue for months, and only recently made some headway in being able to transmit from the NRF52.

https://github.com/TMRh20/nrf_to_nrf  is the source code.

I've also opened an issue to track the problem:

https://github.com/TMRh20/nrf_to_nrf/issues/1

  • 0

    Hi,

    A: Is disabling CRC checking before receiving an ACK while using static payloads correct behaviour? I don't see why CRC checking would be necessary on static ACK packet.

    that shall not be necessary. ACK payload with CRC checking shall work.

    B: How to get receiving working? There has to be something I'm missing, but what? I've tried disabling CRC before sending the ACK, but no luck there.

    There is a restriction in the static payload setup in nRF5-series radios, which only allows for setting one specific static payload length for all pipes. 

     

    Q1: Could you share information related to the nRF24L01+ module that you are using?

    Q2: Have you checked the behavior with nrf_esb examples with similar setup as you're trying to obtain?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Thanks for your reply!

    Q1: Its a standard low-power model nrf24l01+, and I have many different types of modules for testing. (I am the author of the RF24 library https://github.com/nRF24 ) so have a lot of different types. I've tried with a few different ones.

    Q2. No, but my cohort in RF24 programming has, and I believe he had it working with standard nrf24L01+ modules.

    In further looking into this, it looks like the initial packets are being transmitted and received correctly, its just the ACKs that are failing CRC checking on both sides. The NRF24 rejects static payload ACKs from NRF52 and vice-versa. As stated earlier, it works fine with dynamic payloads enabled, even with ACK-Payloads.

  • 0 in reply to TMRh20
    TMRh20 said:
    No, but my cohort in RF24 programming has, and I believe he had it working with standard nrf24L01+ modules.

    Hey, that's me! For the record, I could get the nRF24L01+ to communicate with the nRF Connect SDK using AutoACK packets, but I had to enable dynamic payloads (on both ends obviously).

    There's seems to be a discrepancy between the what the nRF24L01+ datasheet (v2) says about using AutoACKs and what the radio actually allows. In actuality, the nRF24L01+ only requires dynamic payloads enabled if the ACK packet has a payload attached. The nRF24L01+ modules work fine with static payloads + empty ACK packets. However, the ESB module in the nRF Connect SDK (and the nRF5 SDK) seem to have been designed around the inaccuracy in the nRF24L01+ datasheet which tersely states that using ACK packets requires dynamic payloads enabled.

    All that just to say that the SDK isn't a good reference point on this issue because the ESB module only employs ACK packets when dynamic payloads are enabled. Using static payloads with nRF SDKs is more of a "spray and pray" situation.

  • +1 in reply to 2bndy5

    Hi,

     

    2bndy5 said:
    All that just to say that the SDK isn't a good reference point on this issue because the ESB module only employs ACK packets when dynamic payloads are enabled.

    Are you sending ACK payloads with static payload length? If yes, then this is not supported.

    What the nRF24L01+ will do is to send empty packets as payload, ie. payload_size=0. nRF24L will refuse to receive any actual data in an ACK payload if EN_DPL is not set.

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth
    Håkon Alseth said:
    Are you sending ACK payloads with static payload length?

    No I'm not. I realized it was unsupported when I attempted and delved into the SDK src.

Related
Terms of service