Couldn't find any other post that mentions Serial Monitor crippling the normal workflow of the NRF24l01, so here it goes.
I have two Arduino Nano, both with NRF24l01 attached, and an RF24 library working. Both NRF24l01 have 10uF caps soldered on them. One is only sending data, another is receiving only. Both of them flash LED on, successful transmission and successful receiving respectively.
When I run both devices, i see both LEDs flashing, so one succeeds in sending, and another one in receiving. But whenever I try to open Serial Monitor in my Arduino 1.6.1 software, the LEDs flash only every forth of fifth time of expected, and in my Serial Monitor I can see only 1 of 4 or 5 packets received (though received correctly).
Any ideas what I could have done wrong? Could Serial Monitor somehow interfere with Nano talking to NRF24l01?
The code follows, it's simple.
Sender
/*
Copyright (C) 2011 J. Coliz <[email protected]>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
*/
#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
// On Successfull Sending Blink PIN
#define BLPIN 5
//
// Hardware configuration
//
// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(9,10);
//
// Topology
//
// Radio pipe addresses for the 2 nodes to communicate.
const uint64_t pipe = 0xF0F0F0F0E1LL;
void setup(void)
{
pinMode(BLPIN, OUTPUT);
//
// Print preamble
//
Serial.begin(57600);
printf_begin();
printf("\n\rRF24/examples/GettingStarted/\n\r");
//
// Setup and configure rf radio
//
radio.begin();
// optionally, increase the delay between retries & # of retries
radio.setRetries(15,15);
// optionally, reduce the payload size. seems to
// improve reliability
radio.setPayloadSize(8);
//
// Open pipes to other nodes for communication
//
radio.openWritingPipe(pipe);
//
// Dump the configuration of the rf unit for debugging
//
radio.printDetails();
}
// counter data to be sent
unsigned long counter = 0;
void loop(void)
{
// Increase the counter and send it
counter++;
printf("Sending counter = %lu...", counter);
if (radio.write( &counter, sizeof(unsigned long) ))
{
printf("ok...\n\r");
digitalWrite(BLPIN, HIGH);
delay(10);
digitalWrite(BLPIN, LOW);
}
else
printf("failed.\n\r");
// Try again 1s later
delay(1000);
}
Receiver
/*
Copyright (C) 2011 J. Coliz <[email protected]>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
*/
#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
// On Receiver Blink PIN
#define BLPIN 5
//
// Hardware configuration
//
// Set up nRF24L01 radio on SPI bus plus pins 9 & 10
RF24 radio(9,10);
//
// Topology
//
// Radio pipe addresses for the 2 nodes to communicate.
const uint64_t pipe = 0xF0F0F0F0E1LL;
void setup(void)
{
pinMode(BLPIN, OUTPUT);
//
// Print preamble
//
Serial.begin(57600);
printf_begin();
printf("\n\rRF24/examples/GettingStarted/\n\r");
//
// Setup and configure rf radio
//
radio.begin();
// optionally, increase the delay between retries & # of retries
radio.setRetries(15,15);
// optionally, reduce the payload size. seems to
// improve reliability
radio.setPayloadSize(8);
//
// Open pipes to other nodes for communication
//
radio.openReadingPipe(1,pipe);
//
// Start listening
//
radio.startListening();
//
// Dump the configuration of the rf unit for debugging
//
radio.printDetails();
}
unsigned long counter;
void loop(void)
{
// if there is data ready
if (radio.available())
{
while( radio.available() ) {
radio.read( &counter, sizeof(unsigned long) );
// Dump the payloads until we've gotten everything
printf("Got payload %lu...\n\r", counter);
}
digitalWrite(BLPIN, HIGH);
delay(10);
digitalWrite(BLPIN, LOW);
}
}
1 Answer 1
The reason for the Monitor being unable to work properly seems to be the length of the usb cable or a faulty usb port on my computer. I had a usb-cable extender, to which another (this time short) usb cable of my Arduino Nano was attached. It seemed to work fine while I was uploading things to Nano, but a quick serial exchange was, perhaps, not possible.Another usb port, or bypassing the usb cable extender brings everything back to normal.
This is a solution, while I still had no reason, how debugging through serial could influence that much on the chip behaviour itself, until now. I just thought it may well be the same power problem, as FTDI chip both powers the radio (even with the capacitor I installed!) and talks to computer through my long usb cable. If it starts talking, there could be no power for RF24 for a longer period than could be saved by my capacitor.
-
1Are you using the FTDI chip's low-current 3.3v regulator to power your NRF24L01? That might not be a good idea.Chris Stratton– Chris Stratton04/08/2015 18:38:14Commented Apr 8, 2015 at 18:38
-
-
I thought large enough cap (100uF) soldered on NRF24L01 would be enough. Am I mistaken?Grigory Makeev– Grigory Makeev04/09/2015 05:31:19Commented Apr 9, 2015 at 5:31
-
When you use a very long cable you are limiting the total flow of current available to your arduino. The radio takes a lot of current. The cap only stores energy during the time you are not tx and then dumps it when you are. If you tx less often you will have more time to recharge Inbetween dumps. It's possible you were right on the edge of your budget and that the extra cable length made it so that you were running out of juice.benathon– benathon05/11/2015 13:02:56Commented May 11, 2015 at 13:02
-
The radio takes 14mA at maximum, usually a few nanoamps. It could be the capacitator from the power pins that's weak. The regulator ain't great.Avamander– Avamander08/17/2015 23:30:47Commented Aug 17, 2015 at 23:30
radio.setDataRate(RF24_2MBPS)insetup()for each device) and the Mini's success rate jumped from under 50% to over 90%. It might be a bodge - the transmission has finished before the voltage has a chance to drop low enough - but it worked.