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.

From the datasheet, it sounds like RPD is only available in receive mode, but I haven't tested to see for sure if there is any indication with auto-ack.

I'm not sure about the need to calculate an average, because it just returns a boolean value (>64dBM or <64dBM), but I've had decent success in connecting it directly to a variable (signalStrength) and using that to drive an LED via analogWrite. I check it every X ms and removing and re-connecting my external antenna gives immediate results.

The catch with using this method is that the signal strength indicator is only a true indication of if the device is actively receiving data and/or transmitting data.

Datasheet:
The RPD status is latched when a valid packet is received
which then indicates signal strength from your own transmitter. If no packets are received the RPD is
latched at the end of a receive period as a result of host MCU setting CE low or RX time out controlled by
Enhanced ShockBurst.

So it sounds like RPD can be checked at any time 170ms after entering RX mode, but it may indicate the signal strength of interference as well if not used in conjunction with radio.available().

I've been messing around with this lately, and made a simple a 3-level signal status indicator that can be used to indicate signal quality via LED etc.

In order to get the signal strength for all (most) received payloads, testRPD(); can be called just before calling radio.avialable().

bool rpd = radio.testRPD();

while ( radio.available() ){
signalStrength = rpd + 1;
radio.read, etc...
}

Then I also set the signalStrength variable to 0 if a transmission fails, and use the resulting 3-level output to drive an LED. (Bright, Low, Off)

@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