nRF24L01+ RF24 library - can send but can't receive

Question

I'm prototyping out a board with temperature, humidity, windspeed sensors, and using an NRF2401+ board to send values to a Raspberry Pi base station that will record the data.

Using a Leonardo clone board, I'm able to successfully run the pingair_dyn sketch to send test payloads to the RPi and receive acks. (So I know the RPi can send and recieve OK.)

Moving the same NRF2401+ to a breadboard setup with an ATMEGA328P-PU, the same sketch can send payloads which are received on the RPi, but always hits the timeout trying to get the ack (which the RPi is dutifully sending).

In fact when running pingair_dyn as a receiver, it just spins in the loop waiting for radio.available() to return true, which it never does.

The immediate problem is that radio.available() is always returning false. So basically I can send but can't receive.

I have checked my wiring several times, and I'm mostly confident that it's right.

• CE - physical pin 14 (arduino digital pin 8 )
• CSN - physical pin 13 (arduino digital pin 7)
• SCK - physical pin 19, per atmega328 datasheet
• MOSI - physical pin 17, per datasheet
• MISO - physical pin 18, per datasheet

In the software, I construct the RF24 instance:

RF24 radio(8,7);

Any ideas? I tried swapping CE <--> CSN, then nothing worked. Is there some wiring problem that would cause XMIT to work but RECV to fail?

I've tried putting a 2.2 uF capacitor across the 3.3V - GND as I've seen mentioned in other threads, but no difference.

Any suggestions on what is useful information to dig out of the RF24 library to give some idea of what's going on?

More background

Here is the RF24 debug info from the mega328

STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    = 0xf0f0f0f0d2 0xf0f0f0f0e1 
RX_ADDR_P2-5    = 0xc3 0xc4 0xc5 0xc6 
TX_ADDR       = 0xf0f0f0f0d2 
RX_PW_P0-6    = 0x20 0x20 0x00 0x00 0x00 0x00 
EN_AA       = 0x3f 
EN_RXADDR    = 0x02 
RF_CH      = 0x4c 
RF_SETUP    = 0x07 
CONFIG       = 0x0f 
DYNPD/FEATURE    = 0x3f 0x04 
Data Rate    = 1 MBPS 
Model       = nRF24L01+ 
CRC Length    = 16 bits 
PA Power    = PA_MAX

Here is the debug info from the base station (Raspberry Pi): pyRF24/examples/pingpair_dyn/

================ SPI Configuration ================ 
CSN Pin          = CE0 (PI Hardware Driven) 
CE Pin           = Custom GPIO22 
Clock Speed      = 8 Mhz
================ NRF Configuration ================ 
STATUS           = 0x0e RX_DR=0 TX_DS=0 
MAX_RT=0 RX_P_NO=7     TX_FULL=0         RX_ADDR_P0-1     =
0xe7e7e7e7e7 0xc2c2c2c2c2 
RX_ADDR_P2-5     = 0xc3 0xc4 0xc5 0xc6
TX_ADDR          = 0xe7e7e7e7e7 
RX_PW_P0-6       = 0x00 0x00 0x00 0x00 0x00 0x00 
EN_AA            = 0x3f 
EN_RXADDR        = 0x03 
RF_CH            = 0x4c 
RF_SETUP         = 0x07 
CONFIG           = 0x0e 
DYNPD/FEATURE    = 0x3f 0x04 
Data Rate        = 1MBPS 
Model            = nRF24L01+ 
CRC Length       = 16 bits 
PA Power         = PA_MAX

Answer 1

The pins could be wrong for ATMega328.

It should be.

NRF24L01 - Arduino UNO
GND - GND
VCC - 3.3V
CE - 7
CSN - 8
SCK - 13
MOSI - 11
MISO - 12

or B. You need to connect a 500uF electrolytic capacitor to your NRF24L01+ VCC and GND pins directly. To reduce noise related issues. With clone arduinos/cheap regulators/clone NRFs then noise might start creating issues especially with receiving.

Answer 2

FWIW, I had packet loss issues using these boards, until I introduced those 3.3 V piggy back boards to supply current. I use them on both RX and TX now, but experimentation showed that the RX was where it made the crucial difference. Omitting the filter cap also didn't make any difference.

I don't know why these 5 V to 3.3 V piggy back boards were so effective; they're just a regulator. Maybe they've got better quality specs, or their own on board filter caps have a better frequency range for driving the nRF.

They only cost about a $, and save so much agro.

Answer 3

have a look at https://github.com/TMRh20 he's done some great work on the nrf24 radios and has code allowing connection between arduinos and pi's.

Oh and while i've played with non ip addressed data transfer a bit it wasn't the main focus of my research, but shouldn't the tx addresses be matched up?

also you mention a 2.2uf cap on the 3.3v line, but what is supplying the 3.3v line on the arduino side? iirc the pi will supply enough current on its 3.3v line to supply the radio (i remember it working well enough) and i don't know what voltage your running the MEGA at, 3.3v or 5v with level shifters, either way i would imagine your power supply would be sufficient. Unless your running the mega at 16mhz and on a 3.3v (to be stable needs ~4.1v https://electronics.stackexchange.com/questions/58818/programming-3-3v-atmega328-running-at-16mhz) Also iirc most nrf24's are happy enough with 5v logic level, although there are plenty of clones out there, you'll have to do your own testing.

And if you have one to hand would suggest starting off with a non breadboard arduino, get it to work before moving onto the breadboard... there is less that could go wrong :)