Not working: Static Payloads with AA selectively disabled

[TMRh20]

It seems that if you disable Auto-Ack while using static payloads, transmission and reception fails with a CRC error. I'm guessing this is similar to Issue #1 so I'm going to see if I can't figure out what the NRF24L01 is doing here.
The workaround of course is to use dynamic payloads if disabling auto ack.

[TMRh20]

Found the solution:

  NRF_RADIO->PCNF0 = (0 << RADIO_PCNF0_S0LEN_Pos) |
                     (0 << RADIO_PCNF0_LFLEN_Pos) |
                     (0 << RADIO_PCNF0_S1LEN_Pos);

Then the data is in the first 4 bytes of the radio payload.

What I'm curious about here is how the NRF24 does this selectively if acks are dis/enabled on a per-pipe basis, because we can only have one overall PCNF0 config on the NRF52840. That means either we have static payloads with acks, or we don't. I don't think the NRF52840 can do it selectively per-pipe with static payloads. Need to figure this part out before putting in a fix.

[2bndy5]

I don't entirely follow... What's the difference in the sampled solution and the current implementation?

I don't think the NRF52840 can do it selectively per-pipe with static payloads. Need to figure this part out before putting in a fix.

You could track the auto-ack feature via a byte of binary flags (much like the nRF24L's AutoAck register).

Instead, of doing per-pipe control of AutoAck, the SDK relies on emulating the NO_ACK flag from the nRF24L (aka "selective ack" in the docs). Although, there might be a compatibility issue with nRF24L clones/counterfeits. Its my understanding that this clone concern is why RF24Netork uses per-pipe ACK control instead of NO_ACK usage.

[TMRh20]

What's the difference in the sampled solution and the current implementation?

I don't understand the question, but I will try to answer anyway.

I'll have to see how the NRF24 behaves with ACKs enabled on different pipes with static payloads enabled, but basically if you have A: Static payloads enabled B: Acks disabled it uses a different packet format, so the NRF52840 has to set up its packet config different to receive & transmit these payloads. Its fine for transmission, it can be set on a per-pipe basis, but for reception, 52840 can't do it on a per-pipe basis. Again, I have to see wtf the NRF24 does here.

You are correct about RF24Network.

[2bndy5]

Oh, ok. Thanks. Yeah, I can't imagine a solution for RXing a different packet format per pipe on the nRF52.

Maybe if you can get the packet format to use the same format despite the AutoAck setting... This feels similar to how the nRF24L is used for BLE because everything needed for the packet structure is actually in the payload section.

[TMRh20]

Hmm, testing shows the NRF24 does do it selectively. You can have AA enabled on pipe 1, disabled on pipe 2 and it will handle the different packet formats in RX mode.

I guess technically, the 52840 can be set up to receive the packets, calculate the CRC manually, and go from there, but that seems like a bunch of extra steps...

[2bndy5]

The nRF52840 ships with a cryptographic peripheral device. I haven't looking into it much, but maybe that could be used to expedite the CRC calcs in a less manual way. This wouldn't apply to older nRF52/51 family members though. It may also hinder other Arduino libs that actually use the cryptographic peripheral.

[TMRh20]

Yeah, you have some good points. Will have to think about whether to support this functionality and exactly how if so.
It is a pretty specific problem...