Problem with NRF24L01 two way communication

Hi,
in this project I am using an arduino module nrf24L01. For the beginning i tried code with 1 Transceiver and 1 Receiver. Servo and esces, joystick and potenciometer were working. But than I added a lcd monitor to Transceiver and a voltage divider to receiver. I wanted to print the value from the divider (RX) to the lcd (TX). But at this point when I tried to settup 2 way communication everything stopped working. So my question is, how to fix the code to be able to communicate both ways.

I tried to find answers and everyone was saying that this tutorial from Robin is awesome. I tried but i was not able to find answers. https://forum.arduino.cc/index.php?topic=421081

// TRANSCEIEVER WITH JOYSTICK, LCD AND WITH POTENCIOMETER

#include <Wire.h>
#include <LiquidCrystal_I2C.h>
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

RF24 radio(9, 10); // CE, CSN
const byte adresss[][6] = {"00001", "00002"};
int data[3];
float voltage = 0;
LiquidCrystal_I2C lcd(0x27, 16, 2);

void setup() {

  Serial.begin(57600);
  radio.begin();
  radio.openWritingPipe(adresss[1]);
  radio.openReadingPipe(1, adresss[0]);
  radio.setPALevel(RF24_PA_LOW);
  lcd.begin();
  lcd.backlight();
  lcd.clear();
}
void loop() {

  radio.stopListening();
  int joystick_x = analogRead(A0);
  int joystick_y = analogRead(A1);
  int potenciometer = analogRead(A4);
  int val_potencimeter  = map(potenciometer, 0, 1023, 1000, 2000);
  int turning = map(joystick_x, 0, 1023, 0, 180);
  int speed_bldc = map(joystick_y, 0, 1023, 0, 180 );

  
  data[0] = val_potencimeter;
  data[1] = turning;
  data[2] = speed_bldc;
  radio.write(&data, sizeof(data));
 

  radio.startListening();
  while (radio.available()){
  radio.read(&data, sizeof(data));
  data[3] = voltage;
  lcd.setCursor(0, 0);
  lcd.print(  voltage);
  lcd.print( "V");

  }
}
// RECEIVER CODE WITH 2 ESCES, SERVOMOTOR AND WITH VOLTAGE DIVIDER

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
#include <Servo.h>

int data[3];
int readVal;
float voltage = 0;
int readPin = A1;

RF24 radio(9, 10); // CE, CSN
const byte adress[][6] = {"00001, 00002"};
Servo servo;
Servo ESC1;
Servo ESC2;

void setup() {

  Serial.begin(57600);
  servo.attach(4);
  ESC1.attach(6);
  ESC2.attach(7);
  radio.begin();
  radio.openReadingPipe(1, adress[1]);
  radio.openWritingPipe(adress[0]);
  radio.setPALevel(RF24_PA_LOW);

  pinMode(readPin, INPUT);

}

void loop() {
  delay(5);

  radio.startListening();
  if (radio.available()) {
    while (radio.available()) {
      radio.read(&data, sizeof(data));


      int val_potenciometer = data[0];
      int turning = data[1];
      int speed_bldc = data[2];


      ESC2.write(val_potenciometer);
      servo.write(turning);
      ESC1.write(speed_bldc);
    }
  }
  
  radio.stopListening();
  readVal = analogRead(readPin);
  voltage = (11.1 / 1023.) * readVal;
  voltage = data[3];
  Serial.println(voltage);
  radio.write(&data, sizeof(data));

}

I am getting lost in what is added to what plus I have no idea of the original circuit. Please post a schematic, not a frizzy drawing. Robin put this in the top of his code, I wonder why?

// 18 Mar 2018 - simple program to verify connection between Arduino
// and nRF24L01+
// This program does NOT attempt any communication with another nRF24

// 18 Mar 2018 - simple program to verify connection between Arduino
// and nRF24L01+
// This program does NOT attempt any communication with another nRF24

That is in the connection test program that checks communication between the Arduino and the radio module.
The earlier examples are for communication and include a "switch roles" example that does what the OP wants.

OP, did you try the examples with the recommended version of the RF24 library.

I wrote this Tutorial in 2016 when the current RF24 library version was 1.1.7. The Tutorial code has worked without problems until very recently when updates to the library code were made which were not backwards compatible. (To be honest until someone reported a problem with the Tutorial I was not even aware that any updates were being made to the library code - I am still using V1.1.7 for my own projects).

To access the Arduino Library Manager from the Arduino IDE go to Tools / Manage Libraries. After a short delay it wll display a list of all the possible libraries that can be installed. Scroll down to the RF24 library and you can then select the version you wish to install.

It is likely that the Tutorial will work with newer RF24 library versions than V1.1.7 but I don't know which is the first version that is not backwards compatible.

const byte adress[][6] = {"00001, 00002"};

Causes warning:

C:\Users\DaD\AppData\Local\Temp\arduino_modified_sketch_489828\sketch_feb23c.ino:14:41: warning: initializer-string for array of chars is too long [-fpermissive]
 const byte adress[][6] = {"00001, 00002"};

Should be:

const byte adress[][6] = {"00001", "00002"};

To turn on compile warnings in the IDE to see. Go to File, Preferences and set to ALL.

int data[3];
 data[3] = voltage;  // in one sketch
voltage = data[3];  // in the other sketch

Array index out of bounds.

If this were my project, I would use code based on the ackPayload example from Robin2's tutorial.

elderworld:
I tried to find answers and everyone was saying that this tutorial from Robin is awesome. I tried but i was not able to find answers. https://forum.arduino.cc/index.php?topic=421081

Wireless problems can be very difficult to debug so get the wireless part working on its own before you start adding any other features.

The examples are as simple as I could make them and they have worked for other Forum members. If you get stuck it will be easier to help with code that I am familiar with. Start by getting the first example to work

There is also a connection test program to check that the Arduino can talk to the nRF24 it is connected to. If the first example does not work be sure to try the connection test for both of your Arduinos. Nothing will work if the connection test fails.

A common problem with nRF24 modules is insufficient 3.3v current from the Arduino 3.3v pin. This seems to be a particular problem with the nano. The high-power nRF24s (with the external antenna) will definitely need an external power supply. At least for testing try powering the nRF24 with a pair of AA alkaline cells (3v) with the battery GND connected to the Arduino GND.

If you are using the high-power nRF24s (with the external antenna) it may help to have a distance of about 3 metres between the two nRF24s so that the signal does not overwhelm the receiver. However someone on the Forum has had them working without that separation - I don't have any personal experience with them. If you are new to nRF24s it may be better to start with a pair of low power modules with the pcb antenna.

Be sure to take account of the recent comment I added at the top of the Tutorial about the appropriate version of the RF24 library.

...R

Robin2:
Be sure to take account of the recent comment I added at the top of the Tutorial about the appropriate version of the RF24 library.

I think you should adjust the examples to run with the new library.

Whandall:
I think you should adjust the examples to run with the new library.

Feel free to take on the responsibility of reviewing all my examples every time there is a change to the library and identifying and testing any changes that may be needed, and checking whether those changes also work with the older versions of the library and writing notes to explain the changes and (if necessary) explaining any changes that should be avoided if someone is using is using an older version of the library in a legacy project.

...R

I think you should adjust the examples to run with the new library.

I think the new library should be backwards compatible.

Deva_Rishi:
I think the new library should be backwards compatible.

You get what you pay for.

gfvalvo:
You get what you pay for.

That implies that it would have been a significant cost for the library Author to have created the incompatible version as a completely new library and I don't believe it would have taken more than 10 minutes of his time.

Indeed, it would have been even lest costly of the Author's time not to have made any change to the library.

Just because people choose to make their software available for free does not excuse them from being responsible developers. Indeed, to my mind, it places a bigger burden of responsibility on them. Making trouble for people is not helpful, even if it is free.

...R

We are facing the same problem with the IRremote library. Major changes that break all code written for previous versions of the library. I too wonder why they made a new version instead of a new library.

I too wonder why they made a new version instead of a new library.

Let's practice some acceptance and simply keep referring to the library version that works, probably best done within comments of the main .ino file.

Robin2:
Feel free to take on the responsibility of reviewing all my examples every time there is a change to the library and identifying and testing any changes that may be needed, and checking whether those changes also work with the older versions of the library and writing notes to explain the changes and (if necessary) explaining any changes that should be avoided if someone is using is using an older version of the library in a legacy project.

Rubbish.

You know your code fails with the newer version (and why), so change it.
You will have less trouble that way, but that is up to you.

You know your code fails with the newer version (and why), so change it.
You will have less trouble that way, but that is up to you.

Just to have to change it again when the library gets modified again without backward compatibility ? Look it's not my code, but i think we should support Robin. The library was modified without him knowing and he only found out when people couldn't get his tutorial to work.

Relying on an outdated library makes it harder for the people that need help,
that makes it harder for @Robin2 who really tries to help anybody.

IMHO it's just less work (for @Robin2) to fix the now failing examples once.

I did not notice any library dependent difference in my sketches,
at least I haven't noticed it up to now.

Whandall:
IMHO it’s just less work (for @Robin2) to fix the now failing examples once.

I might be tempted to do that if we had a firm undertaking from the library author that all future versions will be backwards compatible.

A long time ago I complained to @TMRh20 because he did not use a new name for his library when he updated the earlier @maniacbug version so he is well aware of my position. Over to him.

…R

1 Like

Robin2:
That implies that it would have been a significant cost for the library Author to have created the incompatible version as a completely new library and I don't believe it would have taken more than 10 minutes of his time.

Indeed, it would have been even lest costly of the Author's time not to have made any change to the library.

Just because people choose to make their software available for free does not excuse them from being responsible developers. Indeed, to my mind, it places a bigger burden of responsibility on them. Making trouble for people is not helpful, even if it is free.

...R

I guess it's just a philosophical difference of opinion. To me this is exactly the same situation as people complaining every time Facebook changes their user interface.

You didn't pay to develop the product, you didn't pay to acquire the product, and you're under no obligation to use the product. You must, therefore, recalibrate the level of support (or even consideration) that you think you're "entitled" to accordingly.

The developer(s), presumably, wrote the code for their own purposes. And, they're making it available for free public use -- AS IS -- under a very liberal GNU license. I think I can understand why they're not overly worked up about your complaints (past and present).

I'm afraid that's just the way the world works.

I see both sides of this.

Yes, when TMRH20 took over the abandoned ManiacBug RF24 library, one commonly used function (read() ) changed its signature, for no really substantial reason, breaking huge amounts of existing code. But that was years ago. In the intervening time the library has developed very well.

Tutorials are useful, especially for less experienced users to get started, particularly if a specific library does not contain sufficient examples.

However, a tutorial which forces a user to revert to an older version of a library may create a bigger problem for that user if he/she then goes on to use other code relying on new features.

In this case, I believe that the tutorial should be either fixed or no longer recommended for inexperienced users. If, in the meantime, the tutorial has been effectively replaced by improved examples in the main library, and no longer has a unique value, it is also questionable whether it should be recommended for inexperienced users.

If, however, the tutorial still has a useful role and the author does not wish to maintain it, then consideration should be given to having it incorporated into the examples section of the main library. At least then, there would be a good chance that it would be tested against any new versions of the library which may appear.

If, however, the tutorial still has a useful role and the author does not wish to maintain it, then consideration should be given to having it incorporated into the examples section of the main library. At least then, there would be a good chance that it would be tested against any new versions of the library which may appear.

That was my initial suggestion. Get it included in the examples, so the people modifying the library will have to make sure the examples still work (or get rid of them, which may be a choice they are willing to make)

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.