Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using payload ack, the ack replied by the receiving end lags 4 times #1002

Open
camerakang opened this issue Sep 19, 2024 · 10 comments
Open

Comments

@camerakang
Copy link

What radio module do you use?

nRF24L01+

What driver board(s) do you use?

esp32-s3-devkitc-1

If using Linux, what OS are you using?

No response

If using Linux, what RF24 driver did you select?

None

Describe your problem

I want the payload ack on the receiving end to reply to the last received data at any time other than the first communication, but now I'm finding that I can't receive the ack four frames ago until after my sender has sent it multiple times

What is the RX code?

https://github.com/camerakang/Nrf24_demo_send

What is the TX code?

https://github.com/camerakang/Nrf24_demo_rev
@camerakang
Copy link
Author

image

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

RF24::stopListening() will flush the TX FIFO when ack payloads are enabled.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

If you're sending ACK payloads to multiple devices/pipes, then (I think) the RX device will only transmit the ACK payload in the TX FIFO's top level (first ACK payload queued) when the payload is received on the pipe intended for the ACK payload.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

Its kind of hard to follow everything your code is doing.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

Tip

RF24::writeAckPayload() returns a bool to tell you if the payload was uploaded into the TX FIFO.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

Have you run our AcknowledgementPayload example? It should demonstrate expected behavior to verify your radio is working correctly.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

        if (ackPayload != NULL && ackSize > 0)
        {
            // ackPayload->counter = result.data[2];
            Serial.print(ackPayload->message);
            Serial.println(ackPayload->counter);

            radio.writeAckPayload(result.pipe, ackPayload, ackSize);
        }

Are you sure ackPayload is never null? This seems pretty clear that the ACK payload will not be uploaded to TX FIFO if this condition is not satisfied.

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

Honestly, this seems like question for Arduino Forums (or PlatformIO forums). I don't think this is a library bug.

@camerakang
Copy link
Author

        if (ackPayload != NULL && ackSize > 0)
        {
            // ackPayload->counter = result.data[2];
            Serial.print(ackPayload->message);
            Serial.println(ackPayload->counter);

            radio.writeAckPayload(result.pipe, ackPayload, ackSize);
        }

你确定ackPayload永远不会为空吗?这似乎很清楚,如果不满足此条件,ACK 有效负载将不会上传到 TX FIFO。

Thank you very much for your reply, I re-read the example about paylod ack and the problem is solved. But I have a problem with setting the channel, I'm modifying the channel using the " radio.setChannel()" function and after the modification I'm printing the current channel via radio.getChannel(), I'm sure that the sender and the receiver are modifying to the same channel but I can't send successfully after the modification. Looking forward to your reply

@2bndy5
Copy link
Member

2bndy5 commented Sep 19, 2024

Its best to call setChannel() while not listening. If the antenna is being used, the radio has trouble tuning it to the specified frequency.

radio.stopListening(); // this will flush TX FIFO if ACK payloads enabled
// radio is now in an inactive TX mode.
radio.setChannel(87);
radio.startListening(); // resume RX behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants