Go Down

Topic: nRF24L01+ and RF24 lib ack failure (Read 12985 times) previous topic - next topic


Hello all,

I have a similar issue with ACK failures.  The transmission always makes it through, but the ACK only makes it back about 20% of the time.

I am using the address mentioned above, and otherwise I'm using the stanleyseow examples for connecting an arduino and a raspberry pi using nrf24's.

Is there anything I can try other than setting that particular address?  I've tried varying the data rate and retries, to no avail.


I have a similar issue with ACK failures.  The transmission always makes it through, but the ACK only makes it back about 20% of the time.
I registered just for replying to this. Probably the original poster won't find this useful any more, but maybe somebody else will.

I had similar "not all acks arriving" problems when I was using voltage boosters on my battery powered sensor. The solution was to add a bigger capacitor right across the radio's VCC and GND pins. In my case previously I was using a 4.7uF capacitor, with that I had about 30% ACK failures, now a 68uF one brought that down to 0.5%. According to this forum ( http://forum.mysensors.org/topic/171/efficiency-of-voltage-boosters ), a Low ESR, high capacitance one (>100uF) can bring it down to zero or very close to zero.

This all boils down to properly smoothing out the voltage for the radio for a stable operation. ( http://en.wikipedia.org/wiki/Decoupling_capacitor )


This thread is still very high in the Google search list for problems with RF24 library acknowledgment, so it may be useful for others to be aware of another cause for failed acknowledgments.

I had 100% acknowledgment failure but excellent message transmission success using an Arduino Uno R3 and a custom board based on the Uno. Acknowledgment was working well using two Unos but failed with my custom board. I naturally suspected a hardware problem but found no issue. Finally, I encountered this issue report about a race condition with changes to the register during the write function. I'm not sure why different hardware causes the problem, but in the report it was first noticed using the Teensy.

I was using a 2013 verison of ManiacBug's library, so I tried the fork by TMRh20 that includes a small wait in the write function. This version of the library addressed the issue. I now have >95% ack success.



I'm having the exact same issue. Send messages are received on the opposite side, but the radio.write() procedure returns false. I just cannot get the reliability high enough. These are some code fragments :

Code: [Select]
#define PIN_CE              7
#define PIN_CSN             8

byte pipes[6] { 0xF0F0F0F0LL, 0xF0F0F0F1LL, 0xF0F0F0F2LL, 0xF0F0F0F3LL, 0xF0F0F0F4LL, 0xF0F0F0F5LL };
RF24 radio(PIN_CE, PIN_CSN);

struct masterData
  byte source_node;
  long message;
  long value;
  unsigned long messageDelay;

struct responseData
  byte source_node;
  bool success;

Code: [Select]
bool BroadcastRadioMessage(byte targetNode, long message, long value){
  int tries = 0;
  masterData radioPayload = { current_node, message, value, 0 };
  bool success = radio.write( &radioPayload, sizeof(masterData));
  while ((!success) && (tries < 10))
    radioPayload.messageDelay = millis() - startTime;
    success = radio.write( &radioPayload, sizeof(masterData));
  return success;

Go Up