I strongly disagree.
Genuine, undamaged and correctly supplied and connected chips
perform as described in the data sheet.
You should not send faster than you can receive,
you should empty the FIFO immediately.
30 ms delays are unacceptable and if really needed,
could be circumvented by using interrupts for the NRF.
Unfortunately, this is not always possible in some scenarios.
For example, if tx has a required tendency to send packets in bursts (eg, when a user is actively interacting with the device), while rx has an occasional 50ms delay. Then it might happen that some packets get acked but my code is not able to retrieve it from the buffer fast enough because of the long delay and whatever other reasons (unstable hardware, unexpected FIFO cleanup etc.) In this case, I would want the tx side to make the decision what to do when rx does not send an ACK in time because the tx side has the sensors and knows when to resend old data and when to replace the data while leaving the same seq number.
Most likely, this is true. However, there are so many "RF24-compatible" boards around being used in projects... So, sometimes it's easier to reinvent the wheel and implement an ACK mechanism that I have full control over, instead of relying on the one that might not work reliably for whatever reason (fake chip, unstable power etc.) and debugging hardware problems ... especially because I'm a programmer and not a hardware engineer 
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.