After much searching, and much experimenting, I finally found a workaround that seems to be working reliably for me. The solution was to use ‘software’ or ‘bit-banged’ SPI. This allows the Ethernet shield to happily commandeer the hardware SPI pins, while the nrf24l01 (or any other peripheral, I suppose) to operate on a separate, emulated SPI bus.

The credit for this goes to a user on the Arduino forums, nicoverduin, who suggested using some software SPI libraries already available and modifying maniacbug’s nrf24 library to use the software spi interface.

Here is the step by step:

1.) Download the modified maniacbug library and softSPI libraries here.
2.) Copy the libraries to your Arduino libraries folder.
3.) Configure your Arduino/Ethernet-shield/nrf24l01 like this (you can also modify the pin configuration if needed. Instructions are in the readme file on the linked github repository):

Once you have completed the above steps, you can upload your sketch to the Arduino and you should be able to browse to the IP of your Arduino with Ethernet shield and you will see a web page that tells you the last message received over the nrf24l01.

There is one major caveat to all of this, however. I have found that sometimes when I am working with the softSPI version of the nrf24 library and then I switch back to the regular/hardware version (e.g. when I work on the sending device, which in this case has no ethernet shield, after I upload a sketch to the one with the ethernet shield), the hardware-based SPI nrf24l01 breaks. This seems to be happening because the Arduino IDE is holding on to the softSPI version of the rf24 library. I am just speculating on that, but it kind of makes sense since the internal naming is identical between the libraries.

The fix for this problem is simple, if a bit inconvenient. I have been removing my modified version of the rf24 library from the Arduino libraries folder before working with the hardware-SPI version. I am sure there is a smarter way of fixing this, and if someone could point it out to me, I would be glad to post the solution here.

In a previous post I described a very simple setup to send and receive data using the NRF24L01 breakouts that can be purchased (very!) inexpensively on eBay. I wanted to show another sketch, using basically the same physical setup, to send and receive text from one arduino to another. Forgive the mostly copy-and-paste nature of this post, if you are just looking for the code, scroll to the bottom.

The image below shows the view of the nrf24L01 from the top. Note: the pins are on the bottom-side. The image shows the top-side.

This is what the breakout looks like from the top.

For this sketch, both arduino boards will need to be setup like this:

fritzing drawing of nrf24l01 connections

closeup of nrf24l01 to arduino connections

Upload the send and receive sketches to corresponding Arduinos physically configured as above. The sending unit will take a string and break it down into individual characters, then send each character until the end of the string is reached. After that, it sends a ‘termination message’, in this case, the integer ‘2’. This tells the receiving end that the message is complete. The sending unit then powers down it’s radio for one second, then powers it back up and runs through the loop again.

You will see some comments in the code about this delay period causing some occasional lost data when sending. I’m hoping someone with more experience with the nrf24 radios can comment on this and provide some code improvements, but this method seems to work well for the most part. I have added an alternative receive-side sketch below that checks for a proper message length as a sort of ‘checksum’ function.

On the receiving end, the sketch begins listening for available messages. Once it begins receiving characters, it begins appending them to the receive string. It continues to append characters until it receives the termination character (again, the integer ‘2’ in this case, but you could set it to something else). It then prints the complete string to serial.

There is a second version of the receive sketch (receive_string_withChecksum) that also checks the final string length against an expected message length. If the actual received message length does not match the expected length, the string is rejected and the radio begins listening for a new message. Obviously, this will only work if you expect a message of a certain fixed size every time.

I couldn’t find any nrf24l01 fritzing parts, so I made my own. The PCB layer needs to be finished, so don’t go sending this out to a PCB fab. It should work great for your breadboard layouts and schematics though.

I have been working with the 2.4Ghz nrf24L01 modules on a few projects. These modules are very inexpensive (about US $1.25 ea. when bought in quantities of 2 or more on eBay), and they seem to work well for short range, small payload data transmittal. This walk-through will show you how to wire them up, and then will demonstrate a pair of very basic sketches (one for the sender, and one for the receiver) used to verify that data is being sent wirelessly.

The image below shows the view of the nrf24L01 from the top. Note: the pins are on the bottom-side. The image shows the top-side.

This drawing shows the basic connections from nrf24L01 to Arduino. For this sketch, the only difference between the sender and the receiver will be that two LEDs will need to be added on pins 3 and 5 (or whichever you choose, really).

closeup of nrf24l01 to arduino connectionsThe send and receive Arduino setups. Pay no attention to the LEDs without resistors.

Once you have the sender and receiver wired up, you will need to upload sketches to each. All the sender sketch does is send values 0 to 255 to the receiver, repeatedly.

On the receiver side, the sketch just reads the sent data and compares it to the last value received. If the value received is equal to the last value plus one, the green LED will light. If it is not, the red LED will light. This works pretty well to visually display how reliable the signal is. If you see lots of red, you know you are dropping packets. Note, though, that this sketch will blink the red LED once each cycle to indicate that a complete 0-255 cycle has taken place.

Again, the idea behind these two simple sketches is to get down to the most basic possible setup for use with nrf24L01. I hope this helps someone trying out the nrf24L01 transceivers for the first time. The video embedded below shows the behavior of the receiver when it experiences lost wireless packets.