Two nRF24L01+/Arduino UNOs don't talk to each other

[oric_dan]

The only way I could figure out what it's doing is to go in and analyze the original
source code. I find I usually have to do this to figure out what the author really did.

[stan001]

I think it's a forked one. But it seems working and arduino's 3v3 was the problem...

I am trying to test with http://maniacbug.github.io/RF24/pingpair_8pde-example.html example. Do you know how can I send an int instead of an unsigned int  so I can test with numbers ?

You shd choose any of the latest RF24 forks... look at the graphs below on github...

https://github.com/stanleyseow/RF24/network

BTW, I got RF24/nRF24L01 working for Arduino UNO, Raspberry Pi, attiny85 and Electric Imp.. all no issues with the 3.3V .. I got my radios from e-bay from 3 sources... see here http://arduino-for-beginners.blogspot.com/2013/02/setup-nordic-nrf24l01-rf-modules-to.html

Any questions or issues, just post it here...

[acboother]

To add to the pot of info...

I have problems with MIRF and RF24 libraries as well - only occasional send/receive successes and not more than 14" apart.

I got maniacbugs to work straight away but have some issues. All 'systems' are straight forward in so much that the is nrf24 plugged straight in with no capacitors and nothing else going on except the examples.

maniacbugs interrupt example has defeated me so far

Also I have replaced the the sending/returning of millis() with a simple counter and, hey ho, I don't like what I find.

I'm often receiving back one or two ackPayloads behind the message that has been sent.

I have also simulated loading the sender and receiver with delay()s in the code and it shows that another layer of validation needs to be added to your own sketches (in my opinion) in order to know what is going on and ensure that your server is returning the correct data to go with the request... I am still working on this as I write...

[oric_dan]

Which specific interrupt example? The basic Getting Started example sketch does not use interrupts.

[acboother]

pingpair_irq.pde

[oric_dan]

Double DOH!! Did you notice this line in the irq sketch

Code: [Select]

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(8,9);

and this line in the Getting Started sketch?

Code: [Select]

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(9,10);

One thing I've noticed is roughly 95% of 3rd party example sketches are full of bugs. I always have to fix these d##mn things. Such is life.

[acboother]

Double DOH!! Did you notice this line in the irq sketch

Code: [Select]

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(8,9);

and this line in the Getting Started sketch?

Code: [Select]

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(9,10);

One thing I've noticed is roughly 95% of 3rd party example sketches are full of bugs. I always have to fix these d##mn things. Such is life.

Yep. I noticed. I've had to disable the IRQ on the sender to allow it to do anything ... and that anything isn't very useful... I also have an issue with the synchronisation of ackPayload replies in pingpair_pl.pde. Not noticeable on the sample as the details are masked by having biggish numbers courtesy of using millis() to generate the data.

At least I feel the underlying code of maniacbug's library is robust for the core functions and the others I've tried don't give me that confidence. I don't want to go trawling through the inards of that sort of code.

Hard at the 'coal face' of NRF24s right now so... chip chip chip.

[oric_dan]

As I previously indicated to hyp3rkyd, I honestly find I have to sift through the source code for most 3rd party libraries, and this seems especially true for RF modules, like RFM12, RFM22, and nRF2401, as there are many setup registers, and some of which the writers assign values, and don't allow changes without hacking the library source. And many examples were obviously created for earlier versions of the libraries, and never updated and cleaned up afterwards, and therefore so buggy. jeenode is horrible this way.

Hopefully, your experiences will be more enjoyable. That said, I'll look at mbug's reasons for using interrupts in some but not all examples, later on - but I have to try and get some work done here this afternoon. Good luck.

[AcmeUK]

Hi hyp3rkyd

I have had the intermittent response failed/timed out problem when I had a low supply voltage to one of my nRF24L01s. I did not need extra capacitors to get them working.

[acboother]

Hi hyp3rkyd

I have had the intermittent response failed/timed out problem when I had a low supply voltage to one of my nRF24L01s. I did not need extra capacitors to get them working.

I had a real problem for a while with message 'drop out's... I had two suppliers of the NRFs and all of those from one supplier ran badly  (!!!) and slow (up to 1/10th the performance) of the batch from another supplier which were perfect. The 'dodgy' lot looked less well manufactured when viewed at close quarters under the magnifying glass as well

I did tell the supplier but they couldn't shed any light on the issue...

How would the typical purchaser of a couple of these units from a single supplier ever know they ran slowly unless you got some, by good fortune, from another supplier than ran faster AND did some tests?

Postings around and about this issue can be found here http://forum.arduino.cc/index.php?topic=178158.msg1376954#msg1376954

[emooney]

Hey hyp3rkyd,

How exactly did you connect the 3.3v to the nRF? Did you go 5v out of the Arduino into the external 3.3v regulator and then into the nRF? If not, what power source did you go off of?

Thanks,
Eric