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

I've been trying to work this out for a while, but need help.

I'm using the sensornet example, but I'm trying to write the data from sensors into a variable.

I guess I'm correct in thinking this is the code that write the data via serial

 RF24NetworkHeader header;
    S_message message;
    printf_P(PSTR("%lu: APP Received #%u %s from 0%o\n\r"),millis(),header.id,message.toString(),header.from_node);

Can someone breakdown whats going on above so I can work out whats going on??

What I'd like to do is import the data into two arrays, "temp_read" and "voltage"

axel12p: The only problem I found, and is shown in the screenshot above, is that every module has to be at least one time in transmission mode before it can listen to the other. So, if I power an Arduino through external power the two modules will never start to communicate with each other. The same happens if for a reason there is a power-off to one of them.

Maybe I'll have to change the code so that the module enters the transmission mode for a while, when it powers up, and then return and remain to receive mode.

I had the same problem. I fixed it by adding the following two lines right after the first instance of: // // Start listening // radio.startListening(); <----FIND THIS LINE, somewhere around line 109

radio.openWritingPipe(pipes[1]); <---ADD THESE TWO LINES AFTERWARDS radio.openReadingPipe(1,pipes[0]);

BDinWa: That, combined with a little payload structure alignment to account for 32-bit vs. 16-bit ints, and everything works for me.

What payload changes did you make? I've not been able to find your code changes.

Following on from this: I managed to get the RF24 library working with the Arduino Due shortly before discovering this thread. I've forked gnulnulf's repo and posted my changes for anyone that may be interested: https://github.com/mcrosson/RF24/commit/ac05a9d8f755dcc7ff12b7e08021f62c0b5f3543

The code was tested using the pingpair_dyn example using a Due and a Micro. You'll need to comment out the fdevopen call on line 30 for the example to compile and run. Near as I can tell the line is not necessary when working with the Due.

Some pics of my setup: Arduino's

Serial Monitor

Hello everyone! Can you tell me how many nodes can have the arduino uno with mesh network topology?

thanks XD

Besides using the version with PA & LNA and external antenna, is there a method to cut the existing PIFA antenna and solder in a "better" DIY antenna to those cheap nRF2L01+ modules ??

Since they are running on 2.4Ghz, there are plenty of DIY antennas made for the wifi radios ..

I still do not understand about the 50 Ohm impedance matching portion for the antenna... The schematics is here -> http://store.diyembedded.com/schematics/nrf24l01p_schematic.pdf

The below links uses a DIY 2.4Ghz antenna with the nRf24L01+ SMA connector...



It seems there is a big gap between the $3 nRF24L01 modules with built-in antennas and the $20 versions with SMA connectors.

After some research I found that the version with both Power Amplifier and Low Noise Preamp was almost the same price as those with only the Preamp or None. Maybe the SMA connector costs more than the chip??

DISCLAIMER: Mentioning stuff from my own shop... but I like these ones, and don't bother with the $3 ones..

How-To on these radios here: http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

Dear Terry,

I have both the "cheap" version that I purchase from China for like 10 pieces for US$12 and the "expensive" version for around US$18...

Since I hv a few extra pieces of the cheap version, I just had this idea of putting a RP-SMA connector to them for the fun of it... but after receiving feedback that the loss from the cables and connectors would be pretty high... it might just defeat the whole purposes of doing it..

that little squiggle is actually matched to the output of the nRF24XX IC, It’s a part of the reference design and every board uses the same parts in pretty much the same configuration. it also is of a type that doesn’t rely as much as other types of antenna’s do on a good ground plane or counterpoise for effective radiation.
The rubber duck type of antenna (flexible or otherwise) is only matched to the transmitter when there is a minimum of 1/4 wavelength radius of metal perpendicular to the antenna and extending for 360 degree’s around it. If the metallic area is larger that’s better if it is irregular the radiation will favor a path along the long axis of the metal acting as a ground plane or counterpoise.
My answer is to use the cheap ones and delegate control of them to a bus controlled processor. The reasoning is that I can get the transmitter as high as necessary while not loosing performance to cabling, either control or RF. Long wires on the SPI bus are a no-no a most strict no-no and any type of usable coax ( not limited by size) is just as bad. The other issue is that other SPI devices will suffer too. So when I need to send a message it has an address too. Much easier that way and I can change between any of the protocols that way becausee the transmitter has some smarts too.


I would give the following a try:


It's a corner-reflector design. Now, I have not done this at 2.4gHz, but I have done it at 850mHz and it worked extremely well (where the driven element was simply the rubber ducky antenna of a handheld scanner.

Orient the nRFL2401 circuit board vertically in the corner with proper spacing from the corner and you should see reasonably good gain even if badly aligned.

I'd just suggest fitting a vertical piece of plastic or cardboard so it bisects the corner of the reflector, and fasten the nRF2401 to that. Tape it down, move it around and look for best performance then mount it more permanently.

I would give the following a try: http://www.freeantennas.com/projects/Ez-10/index.html

THERE's an idea! Thinking outside the Impedance Matching, Feedline and Smith Chart box.

Anyone who tries this let us know. I will when (ItStopsRaining)AND(IGetSomeFreeTime)

Here is a variation of the theme.

Of course there is the Pringles Cantenna option, if you are highly directional. The instructions show cans but you can use a single Pringles can. Its near the perfect size and shape for the target frequency (2.4Ghz).

Absolutely perfect for fixed communications point to fixed point... I do however take exception to DBI (isotropic) rather than the more realistic DBD (Dipole) because DBI involves a conceptual antenna that can't be built. The isotropic antenna is an ideal point source radiating equally in all directions. In fact the built in antenna is directional to a great degree, It favors the open end of the antenna. For a real measure of antenna "gain" measure the RSSI on the other device and have the other device send back the RSSI figures. Without the antenna reflector record the RSSI figure returned from the monitor transceiver and be certain that the measurement isn't maxed out. Reduce the transmitting power on the sending unit by 10 DB and place the reflector in place... If the reflector does as claimed it will bring the RSSI above your measured point... 11.4 DBI is about 9 DB of real gain and it isn't gain but focusing all the power in one direction. This allows a limited area for deploying your other nodes. The high F/B ratio just makes it hard for any not in the direct path of the antenna to successfully communicate with the transceiver. The other issue of course is the connections to the chip from the SPI port, they should be as short as possible unless your controller has nothing else on the SPI bus and all units should be as high as possible above any possible obstructions including but not limited to stucco walls and most types of rolled insulation as most all have a reflective surface of aluminum foil as a heat barrier. There can be issues with any kind of wall material. It just depends on the water content.


I wonder if anyone can help. I just KNOW this is going to be a silly question but..

I'm using one Arduino with RF24 library to send to another - for now just the one direction.... no problem.. If I turn off the transmitting board and turn it back on - all is well... however if I turn off the receiving board and turn that back on - no further sending is possible..

Here's an abbreviated version of my programs missing out all but radio.. what on earth am I doing wrong..

SENDING BOARD relevant inits


RF24 radio(8,3); const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };

SENDING board... the SETUP function..

radio.begin(); radio.openWritingPipe(pipes[0]); radio.openReadingPipe(1,pipes[1]); radio.enableDynamicPayloads() ; radio.setAutoAck( true ) ; radio.powerUp() ; radio.startListening()

SENDING board - the LOOP.

radio.stopListening(); radio.write( &payload, sizeof(payload) ); radio.startListening();

Ok, so now the RECEIVING BOARD


RF24 radio(9,10);

// Radio pipe addresses for the 2 nodes to communicate. const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };


radio.openWritingPipe(pipes[1]); radio.openReadingPipe(1,pipes[0]);

radio.enableDynamicPayloads() ; radio.setAutoAck( true ) ; radio.powerUp() ; radio.startListening();


if ( radio.available() ) { bool done = false; while (!done) { done = radio.read(&payload, sizeof (payload)); }


// some very quick stuff in here radio.startListening();

scargill:     radio.enableDynamicPayloads() ;

    if ( radio.available() )
      bool done = false;
      while (!done)
        done = radio.read(&payload, sizeof (payload));

Note, you are using dynamic payloads. You must do something like:

done = radio.read( &payload, radio.getDynamicPayloadSize() ) ;

See pingpair_dyn.pde as an example.

Payload is always the same size.. I could have used a number. It's the size of a UNION I use to hold the data. I've no problems with transmitting whatsover... the problem comes if I disconnect power to the receiver and reconnect.... The transmitter will no longer talk to it - I don't know whether to change code in the transmitter or the receiver board.

If the payloads are fixed size, then there is no reason to use dynamic payloads. Furthermore, the length provided to write and read determine how many bytes are transferred over the SPI bus with the radio. You should make these the proper size. If in fact they are fixed size, then I encourage you to not use dynamic payloads. Instead, use setPayloadSize() with dynamic payloads disabled. On the other hand, if you are using dynamic payloads, you should use the API properly. If the API is not used properly, there really isn't any point in looking for other issues.

Also, you need to either quote your code, or use something like pastebin. It helps a lot. Furthermore, complete code dramatically improves things.

Do the examples work for you?

Not entirely sure how - but that worked. I've no idea how that dynamic stuff or even the powerup crept in - I've replaced the lot with setting up the payload size, speed etc (256k) explicitly and now after a power-cycle it's absolutely fine.

Thank you for that!!

I found this interesting mini-robot http://www.mowayduino.com/ that uses RF based on nRF24L01+ from atmel blog... http://atmelcorporation.wordpress.com/

Hi! Unfortunately I can’t get it to work on my UNO. Tried several nrf24L01+ so that isn’t the problem. This is my printDetail() : http://pastebin.com/kR86P8D6 and the output when transmitting is

Now sending 8391...failed.

Any ideas?

Thanks, Calle

Hi! Unfortunately I can’t get it to work on my UNO. Tried several nrf24L01+ so that isn’t the problem. This is my printDetail() : http://pastebin.com/kR86P8D6 and the output when transmitting is

Now sending 8391...failed.

Where is the output of the other UNO with nRF ?

Since you didn't mentioned in yr post (and we can't read yr mind), you will need to put the "other UNO/nRF" to Transmit mode to the Pong Back one you pasted the output...