Second time posting about this issue. I have two arduinos set up with the RF24 library. When I run the pingpair sketch, I get 21-23 ms response every single time, no issues.
But whenever I try led_remote, it doesn't work 99/100 times. I am using the sketch right out of the example, the only thing I change is the button_pins and led_pins (both to "3,6", with corresponding connections to leds or buttons).
If I am lucky, right after I upload the sketch, or after i switch ports to the remote arduino and run the serial monitor, I get 1 button press to change the appropriate LED. Then it just keeps failing to send over and over. Even the above trick with uploading the sketch new, or switching the serial monitor doesn't always get me that one signal.
I have tried multiple pairs of modules, I have tried the cap between GND and VCC. Nothing seems to fix it. I have moved the arduinos very close together and far apart (15+ feet).
In looking over your previous post, I would maybe suggest a combination of things:
Use a larger cap (100-220uF or even a bit larger)
Use another, smaller ceramic cap in-line with the first (100nf or so)
Set the pa power to the minimum: radio.setPALevel(RF24_PA_MIN);
Try at 250kbps and 2mbps: radio.setDataRate(RF24_250KBPS); or radio.setDataRate(RF24_2MBPS);
Power the radio separately with batteries (2AA will work), and connect the GND of the battery to the arduino GND - if this fails, its usually not a power supply issue, but something else like some bad modules, interference, wiring, something something...
Also, 22ms response times suggests either something is wrong, or you are using the original library.
The led_remote sketch uses a terminal so you can view/debug what your input/output is doing, compile/upload and when done run the inbuilt serial monitor (terminal) at 57600 baud (speed) to view the data exchanges.
ESSEF:
The led_remote sketch uses a terminal so you can view/debug what your input/output is doing, compile/upload and when done run the inbuilt serial monitor (terminal) at 57600 baud (speed) to view the data exchanges.
You can use any terminal software really but i find Brays to my liking and very configurable the one you can invoke from the Arduino ide is basic but functional.
For future reference
The serial window is a great insight into your micro and even if you dont have any serial data exchanges taking place you can place serial print commands at various points in your software in order to ensure your program is running and executing where its meant to or to find faults .(debugging)
Another method is jtag, with this toolset you can watch your code execute including pin changes /register updates etc etc.
martinwuff:
Do I do this in the void setup section? same question for setting the data rate.
I probably do have the original, but how would I know for certain? Where would I find the most updated version?
Yeah, call this stuff after radio.begin() in the setup section.
Well, I would say the 'most updated' version is my fork at https://github.com/TMRh20/RF24/archive/master.zip in which the master branch should always be considered stable, and any issues reported via the github tracking system. Some of the previous RF24 contributors like S.Seow and G.Copeland have also indicated they are using my fork (which is based on their work), as well as the folks over at MySensors.org so that should tell you something.
Response times with the getting started sketch should generally be a couple of milliseconds, and ack-payloads are usually delivered in less than a millisecond. See Testing New RF24 Arduino Library Fork: Comparative Data Transfers - YouTube for examples of transfer rates with radio modules that are working optimally.
TMRh20:
Yeah, call this stuff after radio.begin() in the setup section.
Well, I would say the 'most updated' version is my fork at
Sorry for the delay. I finally got a chance to download your fork, but now there is a new issue. Yours doesn't have the led_remote sketch. So what I did was pull that one out of the maniacbug version and put it into yours, but now I can't upload the sketch because validation calls out: