I've been suspicious of the order of operations in the begin() function of the RF24 driver.

Specifically these lines:

  // Reset current status
  // Notice reset and flush is the last thing we do
  write_register(NRF_STATUS,_BV(RX_DR) | _BV(TX_DS) | _BV(MAX_RT) );

  // Set up default configuration.  Callers can always change it later.
  // This channel should be universally safe and not bleed over into adjacent
  // spectrum.
  setChannel(76);

  // Flush buffers
  flush_rx();
  flush_tx();

  powerUp(); //Power up by default when begin() is called

  // Enable PTX, do not write CE high so radio will remain in standby I mode ( 130us max to transition to RX or TX instead of 1500us from powerUp )
  // PTX should use only 22uA of power
  write_register(CONFIG, ( read_register(CONFIG) ) & ~_BV(PRIM_RX) );

Theoretically, I think it may be best to reset the IRQ flags and flush the buffers after powering up and entering standby, but the failures are a bit sporadic, so I haven't been able to verify if this will reduce/prevent issues on resetting. A larger user base or additional testing may be able to prove it one way or the other, so thought it worth mentioning.

@lollotek Yup, ask away.

Just a note, if the CE and CS pins are connected wrong, the radio will sometimes have one-way communication, and/or behave oddly as far as acks etc. The RF24 lib has been tested extensively with RPi, and there are no reported bugs or issues with direct RPi -> NRF24l01.

Just to toss my $0.02 in, there are some big advantages to running the nrf24l01 modules directly on the RPi.

The radios themselves have three 32-byte FIFO buffers, and can receive data without any interaction from the RPi. It also has vast amounts of memory and processing power compared to Arduino, so can handle much more complex tasks, and manage data more efficiently.

IMHO the RPi + RF24 is very stable and robust at this point, and is beginning to support a number of Linux platforms directly via spidev and mraa