RF24 Library: Driver for nRF24L01(+) 2.4GHz Wireless Transceiver

Hey everyone!

I am having a bit of trouble running two of these little adapters with an Arduino Mega and a Arduino Nano... it seems to me that the Mega is having trouble reading anything, as I can't get any kind of reply, only a "Failed, response timed out"... However, the Nano receives the packet and sends the ACK. When I reverse the roles, absolutely nothing happens. It does not see any kind of traffic. Packets can go out and never be received. I've attached a screen shot showing what goes on... I'll attach more screen shots later when I get them.

Oh, I'm using the pingpair sketch... also, the GettingStarted sketch does the same thing. One way it works, the other way it doesn't.

Thanks!

This is on the Nano, btw.

This is the results from the pingpair_test.pde sketch...

This is using the Mega to transmit:

and this is the Nano as a receiver:

I noticed that both images do not reflect the same "test", but the results are the same no matter what configuration I use..

It receives it, but the mega doesn't receive the ACK... I'm kind of thinking the Mega is faulty. I know the voltage regulator is bad, for sure. I can't even use the barrel plug to power it.

the nano receive the packet transmited by the mega because adress TX from mega is RC adress of nano.

But the TX adress from nano is not the RX adress of mega. So from ACK isn't received for the mega.

Considering the pingpair code, you've got :

if ( role == role_ping_out )
  {
    radio.openWritingPipe(pipes[0]);
    radio.openReadingPipe(1,pipes[1]);
  }
  else
  {
    radio.openWritingPipe(pipes[1]);
    radio.openReadingPipe(1,pipes[0]);
  }

It shows that there is 2 pipes that allow 2 RF24 to communicate together. Each pipe works in ONE way. That's means that 1 pipe is sending datas in one way, and the other is doing the same in opposite way.

We could show it like considering this code :

The ping out RF24 writes datas on pipe1 and reads data on pipe0

The other RF24 writes on pipe0 and reads datas on pipe1 !!!

We could also show it in another way :

RF24#1 -----pipe0-----> RF24#2
RF24#1 <----pipe1------ RF24#2

In your sketch RX_ADDR_P0-1 are not 'crossed' between the two RF24.

Do you understand what I mean ?

Best regards.

Grag38:

Thanks for the reply, and I totally understand what you mean... I am truly sorry that I may have confused you with different screen shots. I've re-assembled everything and repeated what I did, and got the same exact result, and created two more images.


I must add that I connected the Nano exactly as maniacbug shows on his blog... As for the Mega, I'm using pins 9/10 for CE/CSN, and then pins 50, 51, 52 for MOSI MISO and SCK. Power is coming from the 3.3v from the Mega, however, I may try to use an external regulator when I get home.

Still majorly confused, and thanks for any help, if any.

May be there is an error on wiring mega.

As I read specs of SPI of nano and mega we can discover that :

MEGA :
SPI: 50 (MISO), 51 (MOSI), 52 (SCK), 53 (SS). These pins support SPI communication using the SPI library. The SPI pins are also broken out on the ICSP header, which is physically compatible with the Uno, Duemilanove and Diecimila.

NANO:

SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication, which, although provided by the underlying hardware, is not currently included in the Arduino language.

So, use the PIN 53 instead of PIN10 with the Mega board.

May be it will works as SS means ship select !

Thanks for the input, Grag... I emailed the guy with the bajdi website, since I seen a thread posted by him somewhere in the forum from google results, and he said that his problem was resolved by adding a 22uF or higher capacitor across the Mega's 3.3v and ground. The problem instantly went away!

I'll post pics later :slight_smile:

Hello guys,

I have a very similar problem yesterday when using a NANO and a vero/UNO board (with seperate ucb/serial)
I seemed to have All the symptoms above, I nearly threw the whole lot in the bin...

In the end, I made a second vero/UNO board

My assumption was that 'maybe' the USBinterface on the NANO board was in someway conflicting with timings of the RF board when viewing serial data

All I want is a high speed on way data transfer with no acks, and I got it...
Perhaps I still have some tweaking to go but it seems to work for me :@)

Big thanks for this amazing libary, at the momment I already tried all the examples included, and even made some modifications.

I want to go further but there are some basic concepts I miss, tried on google, in the main site, taking closer look to the examples, but nothing, I just dont understand some things. I really want to go deeper but I feel a good tutorial is missing. Here are some of the things I dont get.

Whats a pipe? How it changes if I want 2 or 6 nodes to speak.

const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
What the numbers mean?

Maybe after the explanation, I will figure how to solve the next issue, but just in case; How do I need to set the pipes if my network is static 6 nodes, one base. The nodes some times send data to the base and then the base answers with some other data back to the emiting node…

Thanks for any help!

I wonder this, if I do this in code:

radio.begin();
radio.setRetries(15,15);
radio.setPALevel(RF24_PA_LOW);
radio.setDataRate(RF24_250KBPS);
radio.setPayloadSize(10);
radio.setChannel(10);
radio.setAutoAck(true);
radio.printDetails();

It's still showing this when I look status of module:
Data Rate = 1MBPS
Model = nRF24L01
CRC Length = 16 bits
PA Power = PA_HIGH

Should radio.setDataRate(RF24_250KBPS); affect immediately?

Should radio.setDataRate(RF24_250KBPS); affect immediately?

I don't know, but I'd try moving the call to begin() to the end.

finnduino:
It's still showing this when I look status of module:
Data Rate = 1MBPS
Model = nRF24L01
CRC Length = 16 bits
PA Power = PA_HIGH

Should radio.setDataRate(RF24_250KBPS); affect immediately?

This will never work, because the 250KBPS speed is only available on the newer nRF24L01+ chip, not the older nRF24L01. Get the data sheets from Nordic and read up on the chip differences.

Thanks much this thread, PaulS and Pico, I got this working at least some way. Now I've Mega which has W5100 ethernet to connect Cosm, and with 433Mhzh transmitter to control Nexa by using it's webserver, and now also nRF24L01+ to read temperatures from Nano with nRF24L01+ ds18b20. This works ok but code looks bad, I think I need to use interrupts, more studying :roll_eyes:

Hi Finnduino,

Can you please tell us more details of how you have the nRF24L01 and Ethernet interfaces wired? What did you need to do to get them both working together?

Thanks!

I've tried several libraries and found this library the best and have the best range... thank you to maniacbug for such a wonderful libraries..

I'm using a compatible wireless module from inhaos.com ? Everything done inhouse ) for my testing...

I've a question to ask, can this library or future enhancements ack similar like serial TX/RX on both sides ?

finnduino:
Thanks much this thread, PaulS and Pico, I got this working at least some way. Now I've Mega which has W5100 ethernet to connect Cosm, and with 433Mhzh transmitter to control Nexa by using it's webserver, and now also nRF24L01+ to read temperatures from Nano with nRF24L01+ ds18b20. This works ok but code looks bad, I think I need to use interrupts, more studying :roll_eyes:

hey finnduino,

just like terryking228, i think it would be interesting to know how you managed to get an ethernet shield working together with a NRF24l01+ module at the same time :wink:

cheers,
stefan

Having following Arduino (clone) 1280 <--> NRF24L01, hopefully I checked these ok:
51: MOSI
GND: GND
52: SCK
50: MISO
48: CE
49: CSN
3V: VCC
GND: GND
Pin6 is connected to 433Mhz transmitter
Pin5 is connected to 433Mhz receiver (not used but just connected)
Pin22 has thermometers (2pcs)
w5100 network board is normally attached to default pins of 1280, not yet any other problems than this is slow...

Some parts of my currently ugly code:
#include <ERxPachube.h>
#include <SPI.h>
#include <Client.h>
#include <Ethernet.h>
#include <Server.h>
#include <Udp.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <NexaTransmitter.h>
#include <RF24Network.h>
#include <RF24.h>

--- clip -- ... and so on
byte mac[] = { 0xE8, 0xB3, 0x3A, 0x30, 0x41, 0x65};
IPAddress ip(192,168,1,13);
IPAddress device(192, 168, 1, 13); // Only if useDhcp is false
IPAddress gateway(192, 168, 1, 1); // Only if useDhcp is false
IPAddress subnet(255, 255, 1, 0); // Only if useDhcp is false
IPAddress dnsIP(192, 168, 1, 1); // Only if useDhcp is false
int ONE_WIRE_BUS = 22 ;
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress thermometer;

//radio:
RF24 radio(48,49);
RF24Network network(radio);
const uint16_t this_node = 0;
const uint16_t other_node = 1;

struct payload_t
{
unsigned long ms;
unsigned long counter;
};

void setup(){

Ethernet.begin(mac, ip,dnsIP,gateway,subnet);
pinMode(ledPin, OUTPUT);
dataout.addData(0);
dataout.addData(1);
dataout.addData(2);
pinMode(txPin, OUTPUT);
// clip enabling Nexa 433Mhz ---
NexaTransmitter remote(6, 12345678); // Create the nexa remote on pin6 with remote id
// radio up:
SPI.begin();
radio.begin();
network.begin(/channel/ 90, /node address/ this_node);
// end setup
//After that there is void loop(), having things like:
network.update();
while ( network.available() )
{
// If so, grab it and print it out
RF24NetworkHeader header;
payload_t payload;
network.read(header,&payload,sizeof(payload));
Serial.print("Received packet #");
Serial.print(payload.counter);
//and so on
}

Here screenshot how test version is currently working, I go to web page, then it at least somehow shows current temperature 25,12'C from sensor connected directy to Mega1280 but also 22'C received from 2.4Ghz sensor. It's sending those values to Cosm and 433Mhz switches are controlled by http GET commands

Thanks to maniac bug libraries, I managed to get both Arduino UNO & Raspberry Pi connected using the nRF24L01+

Hi Stanley

I see in your link the nrf24 lashup on a breadboard. Do you have any trouble with the power supply there. This is in light of discussion at.

http://arduino.cc/forum/index.php/topic,149551.0.html

I see a couple of electrolytics on the breadboard but they don't seem to be related to the nrf24.

I am expecting some nrf24s soon and am currently planning a new proto shield.

I see in your link the nrf24 lashup on a breadboard. Do you have any trouble with the power supply there. This is in light of discussion at.

No issues at all for all Inhaos modules, the regular nRF24L01+ modules or even the ones with PA+LNA and Ext 2dBi antenna...

Are you expecting issues or facing such power issues ??

Stanley:
Are you expecting issues or facing such power issues ??

In the light of your comment, no. I believe these things should be addressed by the board manufacturer in accordance with the recommendations of the chip manufacturer and should not be something for the end user to get too paranoid about.

However there have been some issues and bypass caps have been seen as solution. See the abovementioned link. As to it being the routine solution, who would know?

For all that, I have reserved space on my proto for a tantalum right next to the power pins, so I have no qualms about installing it. I have not yet received my transceivers and I'm just trying to have all the ducks lined up as I have to have everything up and running by the end of May.