Issue with reading/sending data (nRF24L01+)

Projects Programming
1

I hope someone can help me understand why I'm not getting data back from an nRF24L01+ transceiver. I've looked through the forums, but I'm not finding an obvious answer.

I have an Uno set up to request and then read data from up to 4 Mini Pros. They all have nRF24L01+ transceivers. I'm using this tutorial and code to make sure I have the absolute basics of writing and reading figured out: #73 nRF24L01 Send (and receive) data with your Arduino! - YouTube

  • The Uno/transmitter writes an int val to Mini/receiver.
  • The Mini/receiver successfully reads the data
  • I'm not sure if the Mini/receiver successfully writes a new val back to the Uno/transmitter
  • The Uno/transmitter doesn't get the new val back from the Mini/receiver.

Based on the code from that tutorial, the Uno isn't reading data successfully from the Mini Pro. I don't think it's a hardware issue because the Uno was reading data from a Mini before I realized I needed to request data by listening/writing from different pipes.

Thank you for any insight you can offer!

Here's the code for the Uno/transmitter:

#include <printf.h>
#include <RF24.h>
#include <SPI.h>
#include <SD.h>

//I have an SD Card reader set up to record vals. 
//CE/CSN are flipped to share a pin w/the card reader
RF24 radio(8,7); // CE, CSN 

uint64_t pipe[6] = {  0x7878787878LL,
                      0xB3B4B5B6F1LL,
                      0xB3B4B5B6CDLL,
                      0xB3B4B5B6A3LL,
                      0xB3B4B5B60FLL,
                      0xB3B4B5B605LL
                    };
    
const int chipSelect = 4; // For the SD card reader

int counter;

void setup() {
  
  Serial.begin(9600);
  SPI.begin();

  counter = 0;
  
  // GET RADIO INITIALIZED AND STARTED
  
  radio.begin();
  
    radio.setPALevel(RF24_PA_MIN);
    radio.setDataRate(RF24_1MBPS);
    radio.setChannel(124);

    radio.openWritingPipe(pipe[1]);
    radio.openReadingPipe(1, pipe[0]);

    radio.stopListening();
}

void loop() {

  radio.write(&counter, sizeof(int));
  
  counter++;
  
  radio.startListening();

  int dataRx; // the counter val is sent back multiplied by 2
  radio.read(&dataRx, sizeof(dataRx));

  Serial.print("Sent: ");
  Serial.print(counter);
  Serial.print(", Received: ");
  Serial.println(dataRx);

  delay(200);
  
}
2

You've only shown the transmitter code but anyway it does not appear to match your description which implies a periodic role swapping between the transmitter and the receiver part.

But I think you should reconsider this part:

This means that the 4 Mini Pros have to be constantly listening for a message from the Uno. Once such a message has been sent (a) the transmitter has to swap its role to receive the returned message and (b) the receiver has to swap its role to a transmitter to send a return message, then again swap its role to that of a receiver to await the next message from the Uno.

A simpler architecture, and especially if the Mini Pros are battery powered, is to have the Uno listening all the time and the Mini Pros periodically wake up, transmit data, then sleep.

If that, for some reason, does not suit, then you could, instead of the role swapping, use the feature that an acknowledgement packet sent from the Mini Pro, acknowledging the receipt of the packed from the Uno, could contain the returned data.

3

Thank you for your response! I really appreciate it. I looked into the possibility of using the ack function, as you suggested. But I first started by stripping things down (again), and switching from an UNO to a Mega for the receiver/master. What worked in the end was to slow down (add a longer delay) to the sensor modules. What seemed to be happening is that some data was getting lost, even w/multiple pipes/ports open. I had 6 sensor modules writing data to the UNO too rapidly, if that makes sense? Once I upped the delay in the sensory modules (from 200 to 850), I started capturing all of the incoming data.

If this doesn't really seem to be the cause/solution, please let me know because I'd like to understand. Either way, I'm just glad I can start field testing the network.

Thanks again.

p.s., Yes, I have 6 Mini Pros powered by LIPO batteries writing accel and gyro data to the UNO, which is also battery powered. The UNO is writing all the sensory data to an SD card.

4

I can't really aswer that until it is clearer where your priorities are.
There is always a confilct between battery life and other aspects of the functionality.

How frequently are you sending data and what, if any, is your objection to this:

It could be even simpler in that you don't use multiple pipes, which otherwise limits you to 6 transmitters, but simply mark each packet with say a 1 byte sender ID which you handle in your code, that is, if it is necessary to identify the sender of the packet.

5

Thanks. The purpose of this project is to record some of the movements of a horse and its rider. I have 6 battery-powered mini pros on a pcb w/an MPU 6050 (accel and gyro) and the RF24 transceiver. They will be attached to the horse and rider, and I'm recording xyz for accel and xyz for gyro. If the UNO could record 6 new lines of vals from the sensor units, 0-5, every 300 millis, that would probably be ideal, but I keep getting data loss. When I have the delay in the sensor units at 850 before writing again, I get data from all 6 consistently, like 012345012345012345012345, etc. But when I had the delay at 300 in the sensor units, it would be more like 02333354302333330330002111000.

We won't need to record for more than maybe 5-10 minutes each session.

6

You definitely have to have a pause in transmission, especially if there are 6 units transmitting to a single receiver and not synchronized to avoid clashes.

When, say, obtaining data for a weather station, the timings are not so critical, however, in this application where you are looking at relative movement between sensors it looks like the timings are indeed critical.

In that case, also because the sessions are of a relatively short duration meaning battery life is not such an issue, you could look again at adopting the model of the Uno/mega sending a request for data and retrieving the data from the "ack" packet returned from the "Pro Mini".

There are some parameters to play with such as the number of retry attempts, and the interval between such attempts, to make the whole thing a bit more predicatable in the case that there is a problem with the radio reception. That is, it may be better to lose a data item rather than to spend a relatively long time attempting to recover it.

7

I found out that, if possible, I'll want to capture data fast enough for a horse's max cadence of 110-120, so I'm going to look into the ack possibility you mention. (Thanks again). Maybe it'll help me lower the delay in the sensor modules to 400 or 450 millis.

8

I wanted to send a big thanks for your help. I took your advice, and using ack to get data back is a lot faster! I'm getting data back from all 6 modules @ 350 milliseconds w/out data loss. Really appreciate your help!

9

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