nrf24l01 code hang-up

All,
I have a couple of Nanos driving NRFl01+ transceivers. These are being used strictly in a transmitter or receiver mode, they aren’t changing roles. They are not the kind with the large detachable antennas.

The problem is that when the receiver loses contact with the transmitter, the code gets stuck and i have to reset or re-power the receiver. I need it to be a little more reliable.

Inasmuch as this is easily curable by A) moving the receiver, or B)changing to the large antenna type, (maybe) I would prefer to have more robust code, or at least understand why it is completely stopping. There should be a way to detect the issue before it hangs, or break it out of it’s loop or something, but I’m not quite sure exactly what I am running into here.

Below is the receiver code. It’s pretty simple stuff, it just look for a message “123” - if it sees it, it fires a couple of outputs. One is just a light, the other is a transistor that in turn fires a relay. If it sees nothing, the outputs should just go low.

Any advice is appreciated.

#include <SPI.h>
#include <RF24.h>
#define CE_PIN   9
#define CSN_PIN 10
const uint64_t   deviceID = 0xE8E8F0F0E1LL; // Define the ID for this slave
RF24 radio(CE_PIN, CSN_PIN);
int dataReceived[1] = {0};

void setup() {
  pinMode(8, OUTPUT);
  pinMode(7, OUTPUT);
  Serial.begin(115200);
  Serial.println("Receive Starting");
  radio.begin();
  radio.setDataRate( RF24_250KBPS );
  radio.openReadingPipe(1, deviceID);
  radio.startListening();
}

void loop() {
  if ( radio.available() ) {
    radio.read( dataReceived, sizeof(dataReceived) );
    Serial.print("Code received: ");
    Serial.println(dataReceived[0]);
  }
  if (dataReceived[0] == 123) {
    delay(1000);
    digitalWrite(8, HIGH);
    digitalWrite(7, HIGH);
  }
  else  {
    digitalWrite(8, LOW);
    digitalWrite(7, LOW);
  }
}

Are you using this library? Do you have clean power for your modules? What does the Tx part look like?

Btw When you did not receive anything you keep driving your relays . Might not be necessary to tell them again to be high or low

Can you print what is "sizeof(dataReceived)"? (shouldbe 2 just to be sure)

You declare it as an array of 1 int

It would be more natural this way

int dataReceived;
...
radio.read( &dataReceived, sizeof(dataReceived) );

When you say the code "gets stuck" what do you mean ? If the transmission fails, the receiver will continue using the old value in dataReceived[0] because you do not clear this, which could give the impression that the code is 'stuck'.

The issue of power mentioned above is also important because the nano has a very poor 3.3 volt output derived from the USB chip.

Oh yeah, I am using the voltage regulator modules on this as well. They pull power off the 5v supply from the nano.

Power is being supplied by a 9v power supply on the transmitter and receiver. Tried several different versions, didn’t seem to make much difference.

Transmitter code is below.

The final “else” statement with the extra “low” commands on pins 7 and 8 was an attempt at being redundant - earlier versions of this setup were not turning off. That problem has gone away, so you’re right, i could dump that section of the code.

Also noticed that the voltage regulator module and the radio get pretty warm. Not sure if it’s getting stuck in some kind of high power demand while it’s trying to receive, or if it’s getting warm for some other reason and causing the failure.

I will try your code as suggested tomorrow and get the" sizeof(dataReceived)" as instructed.

Thanks again
Wax

#include <SPI.h>
#include <RF24.h>
#define CE_PIN   9
#define CSN_PIN 10
#include <Servo.h>
Servo myservo;

const uint64_t slaveID = 0xE8E8F0F0E1LL;
RF24 radio(CE_PIN, CSN_PIN);
int dataToSend[1];
int oncode = 0;
int servostate = 1;
int closed = 35;
int opened = 130;
int servotime = 5;

void setup() {
  pinMode (7, INPUT);  //current present in coil indicator
  pinMode (8, OUTPUT); //output to LED, active state indicator
  radio.begin();
  radio.setDataRate( RF24_250KBPS );
  radio.setPALevel(RF24_PA_MAX);
 
}
void loop() {
  int coilinput = digitalRead(7);
  if ((coilinput == HIGH) and (servostate == 1))  {
    digitalWrite(8, HIGH);
    servoopen();
  }
  else if ((coilinput == HIGH) and (servostate == 0))  {
    oncode = 123;
    datasend();
  }
  else if ((coilinput == LOW) and (servostate == 0))  {
    digitalWrite(8, LOW);
    for (int i = 1; i < 100; i++)    {
      oncode = 0;
      datasend();
    }
    servoclose();
  }
  else {
    oncode = 0;
    datasend();
  }
}

void servoopen() {
  myservo.attach(6);
  for (int angle = closed; angle  < opened; angle++) {
    myservo.write(angle);
    delay(servotime);
  }
  myservo.detach();
  servostate = 0;
}

void servoclose() {
  myservo.attach(6);
  for (int angle = opened; angle  > closed; angle--) {
    myservo.write(angle);
    delay(servotime);

  }
  myservo.detach();
  servostate = 1;
}
void datasend() {
  radio.openWritingPipe(slaveID);
  dataToSend[0] = oncode;
  radio.write( dataToSend, sizeof(dataToSend) );
}

The regulator on the nano will not be very friendly to a 9 volt battery and burns off the excess voltage as heat. If the transceivers are close to each other, you can reduce the power, for example:

radio.setPALevel(RF24_PA_LOW) ;

to stop swamping. https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

The examples in my Simple nRF24L01+ Tutorial don't have any problem when either the Tx or Rx is temporarily disconnected. They continue on as normal when the device is reconnected.

If you are using the ManiacBug version of the RF24 library that might be the problem - I switched to the TMRh20 version of the RF24 library becuse of problems when I tried to increase the interval between messages with the ManiacBug version.

...R

Hi, Can you post a picture of your two projects please? So we can see your layout.

How close together do you have the two units, if they are close you will have a problem with Rx overload. "NRFl01+ transceiver" what model is it, does it have the power amp and external antenna?

Thanks.. Tom.... :)

TomGeorge: if they are close you will have a problem with Rx overload.

I have never had a problem like that. For most of my tests the two nRF24s are on the same table in front of my laptop. I suspect this is an issue for the high-power devices with external antennas - but I don't have any of them.

...R