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

[Grag38]

Thanks a lot ManiacBug.

I use RF24 to talk about the hardware and your nice library because the both are linked together ;O)

I'll try when I will receive my other RF24 hardware, I just own 2 for the moment, and it works very well.

And 'BRAVO' for this very usefull library you made, it's clear and easy to use. thanks.

Grag38

[DeB86]

Hi guys,
thank you for the libraries they are great and I have done a broadcast configuration and it works really good.
Now I should get the board addresses that had received the broadcast packet, so I can list them on the serial interface and then collect them in a PC software.

Is that possible?

Thank you really much.

[Rustie0125]

Hi Guys.

I have two problems/questions
I have been playing with the nRF24L01 units for awhile now , and I have most of the examples working but I get a compile error when trying to verify the code . the code im trying tomake work is the sensornet pde. but i keep getting eeprom_update_block not declared. I have redone the file paths and and redownloaded the code but i get the same error over and over, and all the other examples work so that would tel me that the file path is fine.

im using 2x UNOs and IDE1.0.1
any ideas to fix this would be great.

the other problem i have is more on of advice needed. i want to use these units as maniacbug did for the sensor net but i want to send GPS data ,voltage and tempreture and date. which example would be best to start with and what would you suggest to use to send this data ?

[Rustie0125]

Anyone ?

[scargill]

I wonder if anyone can help. I am using RF24 and RF24NETWORK. I'm putting together a home control setup which I'm quite happy to share - but I have hit a bottleneck.

My only change to RF24NETWORK is to set the speed to 256k as tests have shown this can up the range by 25% or thereabouts - I'm sending packages of no more than a few bytes so that's fine.

I have 3 devices sitting in the same room right now - 0, 02 and 022.  I've set up a master slave arrangement.... 02 is doing nothing but sitting in a loop calling network.update() - and because of that, devices 0 and 022 can talk to each other.

The problem is - understanding that only one device can talk at once etc... I've set up a master-slave arrangement.

I've been having timeouts occuring and so I've simplified the coding...

Unit 0 sends to unit 022.
Only when unit 022 gets a response does it immediately send back a response to zero.
As soon a unit 0 gets a response from 022 it sends another package to 022  - and so on ad-infinitum.

In 022 I've set a led to come on when something is available and go off after receiving - so I can see packages coming in.

As you'd expect there is a constant stream of data keeping the LED on more or less constantly--- except - it keeps stopping for a fraction of a second - or even for a second.  Worse if you do any other minor jobs in the loop it gets worse to the point where processing a few input and outputs, reading the real time clock etc makes for large gaps... none of these external processes takes any time and the code I've written, really should just work - as I'm waiting for a reply from one device before talking to another - given that the NRF24L01 devices have a tiny amount of buffering I'm at a complete loss where these timeouts (or that's how it seems) are coming from.

Anyone have any ideas?

[tack]

Hi everyone. I'm trying to get to grips with the nRF24L01 and the RF24 & RF24Network libraries.

I have made my own breakout boards for my RF units, which are 10 pin configuration. Vcc and Gnd are doubled up on pins 1/2 and 9/10 respectively.

So, I've wired them, checked all my soldering and continuity between the wire ends, my board connections and through to the units when plugged into a 2x5 female header on my breakout. Everything checks out fine and, when plugged in and Arduino powere up, I see a nice 3v3 at across Vcc and Gnd.

I've then connected to each Arduino as:-

CE - D9
CSN - D10
MOSI - D11
MISO - D12
SCK - D13
IRQ - Not Connected at the moment (I believe it's redundant unless use required)

Then I have my two Arduinos (an SMD and DIP version), with each nRF connected, and running the GettingStarted sketch with no changes.

Code: [Select]

Arduino 1 (SMD)

RF24/examples/GettingStarted/

ROLE: Pong back

*** PRESS 'T' to begin transmitting to the other node

STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e77f 0xf0f0f0f0d2
RX_ADDR_P2-5 = 0xc3 0xc4 0x7f 0xff
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x3f
RF_CH = 0x4c
RF_SETUP = 0x57
CONFIG = 0x7f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGH


Code: [Select]

Arduino 2 (DIP)


RF24/examples/GettingStarted/

ROLE: Pong back

*** PRESS 'T' to begin transmitting to the other node

STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xf0f0f0f0d2 0xf0f0f0f0d2
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 = 0x03
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power                = PA_HIGH


You can see that mine differ at the addresses to the example posted on the maniacbug blog

Code: [Select]


RF24/examples/GettingStarted/
ROLE: Pong back
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 = 0x08 0x08 0x00 0x00 0x00 0x00
EN_AA                = 0x3f
EN_RXADDR = 0x03
RF_CH                = 0x4c
RF_SETUP = 0x07
CONFIG                 = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model                = nRF24L01
CRC Length = 16 bits
PA Power                = PA_HIGH


I appear to have different address results i the debug code, despite the sketch settin these to

Code: [Select]

const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };

I'd appreciate any help here as I've spent hours on this and it's driving me nuts just not being able to get the default example to work, before I start trying to use these to transmit some small packets of data back to a root node with Ethernet and on into web based system.

[tack]

Right, some kind of progress, but even more puzzles:-

Occaisonally when resetting, one of my units will show the addresses (pipe) as E2 & D2, whilst the other shows both as D2.

If I try transmitting from the E2/D2 then I get nothing. If I try transmitting from the D2/D2 then the E2/D2 responds as you expect and works ping/pomg. If I then change the D2/D2 to 'R' and the E2/D2 to 'T; then it works again! Strange, it will only work that way round AFTER I've had it working the opposite way.

I suspect that if both units show E2/D2 correctly then I could reliably transmit from either first and it will work.

Anyone have any idea as to what is going on here?

[Grag38]

Not shure it can help you, but...

RF24 system works with pipes, 1 for TX and 6 for RX with one module.

between 2 RF24 if you want them to communicate you must set these pipe according for TX/RX of each device.

Lets say :

RF24 #1  :

TX pipe = 0xF0F0F0F0E1
RX pipe = 0xF0F0F0F0D2

so from RF24 #2 must be as :

TX pipe = 0xF0F0F0F0D2
RX pipe = 0xF0F0F0F0E1

when RF24#1 is transmitting on E1, then RF24#2 will listen on E1. When RF24#2 wants to transmit datas to RF24#1 it sends on D2 and RF24#1 listen on D2.

With your code it seems there is a trouble because the DIP module use the D2 as TX and RX... so it will 'ear' only what it sends himself in my guess.

I used the maniacbug code : GettingStarted without modification and it works well !

And at last, one RF24 must be in role_ping_out and the other in role_pong_back, it seems not be the case of your print from your arduino (dip and smd show pong_back !!!)

Hope it can help you.

Also there are a lot of comment on maniacbug website, concerning the RF24 class.

we can read on it :

void RF24::openReadingPipe    (   uint8_t    number,
      uint64_t    address
   )      


Open a pipe for reading.

Up to 6 pipes can be open for reading at once. Open all the reading pipes, and then call startListening().
See also:
openWritingPipe
Warning:
Pipes 1-5 should share the first 32 bits. Only the least significant byte should be unique, e.g.
  openReadingPipe(1,0xF0F0F0F0AA);
  openReadingPipe(2,0xF0F0F0F066);
Pipe 0 is also used by the writing pipe. So if you open pipe 0 for reading, and then startListening(), it will overwrite the writing pipe. Ergo, do an openWritingPipe() again before write().
Todo:
Enforce the restriction that pipes 1-5 must share the top 32 bits
Parameters:number   Which pipe# to open, 0-5.
address   The 40-bit address of the pipe to open.

void RF24::openWritingPipe    (   uint64_t    address   )   


Open a pipe for writing.

Only one pipe can be open at once, but you can change the pipe you'll listen to. Do not call this while actively listening. Remember to stopListening() first.

Addresses are 40-bit hex values, e.g.:
  openWritingPipe(0xF0F0F0F0F0);
Parameters:address   The 40-bit address of the pipe to open. This can be any value whatsoever, as long as you are the only one writing to it and only one other radio is listening to it. Coordinate these pipe addresses amongst nodes on the network.

Hope it can help you.

Best regards

[danoduino]

First let me say thanks to maniacbug for the GREAT library!

I've playing around with these modules for a few weeks and decided to base my sensor xmitters on the pingpair_sleepy example.  I wanted to reduce power consumption as much as possible.

I came across a problem in the pingpair_sleepy example provided with RF24.  The ping out would only work once.

    // Power down the radio.  Note that the radio will get powered back up
    // on the next write() call.
    radio.powerDown();

When the radio was powered down, it would never come back.  Commenting out radio.powerDown(); OR adding radio.powerUp() before the radio.write call in the example works.

Maybe there's a bug that assumes a write will always powerup first.

I hope this helps someone!

My sensor works well now and draws ~20ma idle (4secs) and ~35ma (1sec) when sending data.

Thanks.

[ominously]

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.

[ominously]

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.

[Grag38]

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 :

Code: [Select]


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.

[ominously]

----

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.

[Grag38]

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 !

[ominously]

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