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

I would add a large capacitor across 3.3v and gnd. I have had issues with the power supplies on arduinos (chinese clones :p), and that solved it every time. And I am going to attempt to make a wireless DMX transmitter with these transceivers, which will require sending a 512 byte packet at least every 50 ms. Any suggestions on optimizing settings and code to be able to pass data at this speed? I read earlier in this thread about removing the delays in the write function, should I do that?

Any help would be great,
ematson5897

ematson5897, much thanks that did it.

wow i really cant believe it, the 24l01 pulls next to no current too! wow cheap Chinese crap!!!! they probably dont even test to see if the power supply can handle any they of load! added two 100uF caps one one each module. I wonder if reducing the ripple even more will help in reception, ie increase the range, hmmmmm

again thanks :slight_smile:

No problem! And yes it should receive less noise, so you might be able to get away with longer distances

I was thinking of 10 mike tantalums I have to hand

Also I found a documentation error. The code and documentation do not line up for the setPALevel command

void RF24::setPALevel ( rf24_pa_dbm_e level )
Set Power Amplifier (PA) level to one of four levels.

Relative mnemonics have been used to allow for future PA level changes. According to 6.5 of the nRF24L01+ specification sheet, they translate to: RF24_PA_MIN=-18dBm, RF24_PA_LOW=-12dBm, RF24_PA_MED=-6dBM, and RF24_PA_HIGH=0dBm.

Parameters:
level Desired PA level.

/**
 * Power Amplifier level.
 *
 * For use with setPALevel()
 */
typedef enum { RF24_PA_MIN = 0,RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX, RF24_PA_ERROR } rf24_pa_dbm_e ;

You use min,low,high,and max in code but docs say otherwise

And for those interested, I am porting this library to energia (arduino for ti launchpad)

Great library and great job from maniacbug!

I am using 2 Arduino UNOs with 2 nRF24L01+ on top, bought from iTeadStudio.

When using the RF24 library I am facing the exact same problem as egghead did. I am receiving STATUS at the beggining, but only "Failed, response timeout" when trying to transmit. I will try to connect a capacitor between 3.3V and GND pins to see if this can fix the problem.

On the other hand, when trying the RF24Network library, the network seems to operate fine, with only minor problem some dublicates showing up on the serial monitor (Received packet #544 at 109000, Received packet #544 at 1090000).

So I can not figure out if the RF24 library is suitable for the nRF24L01+ modules or the simple ones. Do I have to use only the nRF24Network library, to make my modules work?

axel12p:
When using the RF24 library I am facing the exact same problem as egghead did. I am receiving STATUS at the beggining, but only "Failed, response timeout" when trying to transmit. I will try to connect a capacitor between 3.3V and GND pins to see if this can fix the problem.

On the other hand, when trying the RF24Network library, the network seems to operate fine, with only minor problem some dublicates showing up on the serial monitor (Received packet #544 at 109000, Received packet #544 at 1090000).

So I can not figure out if the RF24 library is suitable for the nRF24L01+ modules or the simple ones. Do I have to use only the nRF24Network library, to make my modules work?

Which example sketch are u using ??

Can you paste the output here in ...

RF24Network are using the RF24 libs.. so if RF24Network is working, then RF24 libs "should" be working...

For debugging, I suggest putting some Serial.println() statements at various checkpoint to "see" what is going on with the radio/libs.. was the timeout caused by other reasons...

I even use radio.available( &pipe_num) to loop thru the 6 pipes one by one to "see" what's going on...

For yr case, it should be just using pipe0 and pipe1 ...

http://maniacbug.github.com/RF24/classRF24.html#ace7dd139fabc16b77cb8325faa07620f

You should use the "latest" fork RF24 libs from others....

To fix my Mega issues I used a 47uF cap and a .1 uf cap right at the connector and 0805 parts solder nicely between .1"/2.54 cm pins.. , Just stack them like bricks.

Bob

Firstly I would like to thank you both for your help!

My hardware configuration is the same as this mentioned in maniacbug's blog (Getting Started with nRF24L01+ on Arduino | maniacbug). I have double checked the wiring and everything seems to be fine. I have also tried to connect the RF modules to Arduino boards through female to male wires but nothing changed. I have bought five RF modules and tried several combinations with no luck. My Arduinos are UNO R2 and R3, but I don't think that this matters.

The libraries I have installed were those from maniacbug's github (maniacbug · GitHub). I have downloaded the zip file and extracted it to my libraries folder.

As you can imagine, the first example that I have tried, was the "GettingStarted" example. The first Arduino is powered throught the USB cable and the other through a 5V wall adapter.
When I open the Serial Monitor I am getting the result shown below:

If I interchange the position of the two Arduinos I am receiving this:

As you can see the wiring seems OK (I don't receive any zeros), but there is also no communication between the two modules.

The strange thing is that when I' ve uploaded the helloworld_tx and helloworld_rx examples included in the RF24Network library, a connection has been established between the two modules (messages like: "Received packet #544 at 109000" showed up at the Serial Monitor of the receiver).

I didn't knew that newer libraries have been released, so I tried earlier the RF24 library from gnulnulf with the exactly same results :frowning:

I will try to put some Serial.println() statements to the code for debugging and also add a capacitor between 3.3V and GND pins (I also have some 0805 SMD capacitors) hoping that any of these solutions may help...

axel12p:
When I open the Serial Monitor I am getting the result shown below:

Yr TX_ADDR is wrong... pls re-check yr codes.. it should be 0xf0f0f0f0e1 for BOTH the units from the example...

Yours is f0f0f0f0d2 and e7e7e7e7e so they r NOT communicating with each other... RF24 will ignore packets with TX/RX address not matching the list on the RX pipes...

Hello,

This is what I'm also getting.

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

However, on a random basis, Serial Monitor is displaying :
RX_ADDR_P0-1 = 0xf0f0f0f0e1 0xf0f0f0f0d2
OR
RX_ADDR_P0-1 = 0xe7e7e7e7e 0xf0f0f0f0d2

Seems the address is not setup, therefore the default one is used (0xe7e7e7e7e).

I tried to reset many time / upload, and time to time ADDR is setup properly.

Any clue.

Regards.

Mersing:
However, on a random basis, Serial Monitor is displaying :
RX_ADDR_P0-1 = 0xf0f0f0f0e1 0xf0f0f0f0d2
OR
RX_ADDR_P0-1 = 0xe7e7e7e7e 0xf0f0f0f0d2

Seems the address is not setup, therefore the default one is used (0xe7e7e7e7e).

I tried to reset many time / upload, and time to time ADDR is setup properly.

Any clue.

You could try this simple libs to ensure the SPI communication hv no errors/data corruption...

https://code.google.com/p/rfsync/

It was written (by someone else) using the minimum stuff... the Inhaos are h/w compatible with NRF transciver except for the 250Kbps speed..

Stil nothing, I can't figure out what's wrong :frowning:

I have connected the 2 Arduinos on the same PC (COM6 & COM7) and uploaded on them the GettingStarted example as is.

Below you can see what I am receiving on both Serial Monitors

Arduino on the right says that it is getting the payload and sents responses, which 99% of the time the Arduino on the left doesn't receive...

The wierdest thing is that when I am using Arduino on the right as a transmitter the other Arduino doesn't show anything on its Serial Monitor.

Sometimes when I reopen the Serial Monitors, the TX_ADDR are not the same between the 2 Arduinos (propably they hold their last state) but the results remain the same as you can see:

I have also tried to solder a 10uF capacitor between 3.3V and Gnd pins but with the same results.

axel12p:
Stil nothing, I can't figure out what's wrong :frowning:
I have connected the 2 Arduinos on the same PC (COM6 & COM7) and uploaded on them the GettingStarted example as is.
Below you can see what I am receiving on both Serial Monitors

If yr output is shown, the SPI comms to the radio is OK..

When I re-wrote my codes, I find the example might work for the ping/pong but not for actual codes without adjusting the other settings like delays/settings...

Try the following one by one...

  1. Put debug serial.print statement inside the while loop :- while ( ! radio.available() && ! timeout )
  2. changing the RF_CH on both ( rule out any radio interference... )
  3. lowering the PA_Power on both
  4. Increase the timeout of 200 at line : if (millis() - started_waiting_at > 200 )
  5. reduce/increase the delay(1000) but higher than timeout period
  6. Try another Serial examples at nRF24L01 serial like synchronous bi-directional communication - #9 by stan001 - Networking, Protocols, and Devices - Arduino Forum
  7. swap the radios on the Arduinos
  8. I usually do not mess with the h/w side of soldering/desoldering as it might spoil the RF module

Thank you very much for your help. Hopefully I didn't have to go through all these steps because the problem has been partially fixed.

As I was looking at the outputs on the Serial Monitor of the two Arduinos, I figured out that there should be a problem with one of the two Arduinos, receiving data but not sending. As you can see in the screenshot of my previous post, the Arduino on the right sends responses but the Arduino on the left isn't receiving anything.

So, I disconnected the RF module from the protoboard and connected it to the Arduino through male-to-female wires. Below you can see the result after doing so:

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.

axel12p:
Thank you very much for your help. Hopefully I didn't have to go through all these steps because the problem has been partially fixed.

As I was looking at the outputs on the Serial Monitor of the two Arduinos, I figured out that there should be a problem with one of the two Arduinos, receiving data but not sending. As you can see in the screenshot of my previous post, the Arduino on the right sends responses but the Arduino on the left isn't receiving anything.

So, I disconnected the RF module from the protoboard and connected it to the Arduino through male-to-female wires. Below you can see the result after doing so:

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.

Yes, did I mention that I usually put a few of my arduino + nRF on 16x2 LCD (pics on my blog) so I do not even connect them to PC/Serial Monitor... and I change the code to force one of them to RX mode and auto-reply back to sender...

Just put two lines, radio.stoplistening() and radio.startlistening() to enable TX mode then back to RX mode..

You are very near to solving yr radio issues..... haha...

Stanley:
You are very near to solving yr radio issues..... haha...

Jeez, Stanley, are you getting up early or going to bed late?

I have the network code working perfectly using DS18B20 temp sensors on a pair of Megas, and am now trying to get a Due working.
Lots of compile errors using 1.5.2
fixed all the errors related to printf_p and PSTR, but there seem to be lots of issues with SPI
Any thoughts on the move to the Due?

Nick_Pyner:

Stanley:
You are very near to solving yr radio issues..... haha...

Jeez, Stanley, are you getting up early or going to bed late?

Nick...
I woke up early after falling asleep last night at 10pm!!!!

BDinWa:
I have the network code working perfectly using DS18B20 temp sensors on a pair of Megas, and am now trying to get a Due working.
Lots of compile errors using 1.5.2
fixed all the errors related to printf_p and PSTR, but there seem to be lots of issues with SPI
Any thoughts on the move to the Due?

Pls look at :-

Pls fork the latest version and work on the lib for the Due.... once it is stable, we can merge it back to the main libs..

We had a GPIO working version for RPi (also ARM) and we are porting to a h/w version directly from the bcm2835 Soc...