Possible error in nRF5 SDK for ESB DPL transmissions with "selective auto ack" (

[mame82]

Hi folks,

I've found no beeter way of reporting this (no public SDK repo which allows issues with code reference).

I tried to TX ESB DPL frames from an nRF52840 to different versions of nRF24. The frames made it on air, but didn't get acknowledged.

To make a long story short, I assume the following code in  `nrf_esb.c` is wrong:

static void start_tx_transaction()
{
    ...snip...

    switch (m_config_local.protocol)
    {
        case NRF_ESB_PROTOCOL_ESB:
            ...snip...
            break;

        case NRF_ESB_PROTOCOL_ESB_DPL:
            ... snip ...
            // note: noack shouldn't be negated befor OR'ing onto S1 field
            //m_tx_payload_buffer[1] |= mp_current_payload->noack ? 0x00 : 0x01;
            m_tx_payload_buffer[1] |= mp_current_payload->noack ? 0x01 : 0x00;

            memcpy(&m_tx_payload_buffer[2], mp_current_payload->data, mp_current_payload->length);

... snip ...

The unmodified code leads to RF frames with "no ack" bit in PCF set if the "noack" bool in the `nrf_esb_payload_t` struct is false.

So the flag is effectivly negated, leading to unintended behavior in PTX mode with selective acknowledgement.

Regards,

Marcus

[mame82]

Addition: This is for SDK 15.2, haven't checked 15.03.

A code repository with issue tracking would be helpful (referencing codefiles, lines etc.) would be helpful and ease up reporting such issues (version agnostic)

[Kenneth]

Hello,

Can you provide detailed chip marking on the nRF24L- devices you are using here? Have you bought these through a nordic distributor?

Best regards,
Kenneth

[mame82]

Sorry, I can't provide reliable info on this, as my peers are different Unifying dongles.

For CU0007 I assume nRF24LU1+, while CU0012 is assumed to be TI CC2544 (shows same behavior).

Other peers I used are all nrf52840 (Nordic USB dongle, Makerdiary MDK, Makerdiary MDK USB Dongle) .

To be honest, everything works as define per specs: If a frame with "no ack" bit set is sent to a PRX with "selective auto ack" there's no ack in reply.

The problem is, that I have to set the "noack" boolean to true in the nrf_esb_payload_t struct, to get an RF frame with unset "no ack" flag bit transmitted (when using selective ack in TX on nRF5 SDK).

The code snippet which is responsible for this "flag negation" is part of the initial post (wring version commented out, correct version in line below).

[mame82]

Alternatively the "noack" boolean from nrf_esb_payload_t could be renamed to sth like "requestack", but this wouldn't fit esb PCF specs

[mame82]

Ping

[Kenneth]

Hi, you can find some interesting discussion around the noack bit in this thread (search for 'noack'):
https://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/93 

In short there was an error in the old ESB documentation regarding the noack bit, the description was reversed. So the current SDK implementation should be correct as long as the nRF24L have enabled the EN_DYN_ACK feature in the first place (enable noack command).

[mame82]

The forum thread didn't add up much for clarification, thus I try to sum up in my own words ...

Setting the `noack` bool on a `nrf_esb_payload_t` struct to true results in a RF frame with 'no ack' bit unset in PCF (or S1 field if you like better) after TX. This could be inspected with SDR or whatever you like, no need to use another peer, with (in)compatible chipset. If this is intended behavior, we could close this issue immediately (although IMO this is weird). BUT if setting the `noack` bool of `nrf_esb_payload_t` to true should result in a RF frame with `no ack` bit set, the line of code highlighted in the initial post has to be changed.

Nothing complicated here ... the simple  question is: Should the application layer logic (nrf_esb_payload_t) be consistent with the RF layer (no ack bit of RF frame) or should it not?

If it should not be consistent, which isn't the natural expectation, I'd be happy to receive a link to proper documentation.