Troubleshooting NRF24, or other options

I have a project where I need to transmit 2 bytes of data at a time, around 120 times per second, preferably more, but thats the bare minimum. This needs to be done with near 100% reliability, with a range of about 5 meters, through a plastic enclosure.

Right now, I'm using two genuine Arduino Unos connected to an NRF24L01 module. Included is a picture of the wiring for one, which is identical on the other. I am using a simple breakout board to use them with a breadboard. Both modules are connected to the 3v3 supply of the arduinos and have a 10uF ceramic capacitor accross the supply.

For a test code, I have the transmitter sending an alternating 2 byte sequence of 0x0000 and 0xFFFF. The receiver accordingly turns on an LED when it receives 0xFFFF and turns it off when it receives 0x0000.

Transmitter Code:

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


RF24 radio(9, 10); // CE, CSN


const byte address[6] = "00001";

uint16_t sendData = 0xFFFF;
uint16_t sendData2 = 0x0000;

void setup()
{
  radio.begin();
  radio.openWritingPipe(address);
  radio.setPALevel(RF24_PA_HIGH);
  radio.stopListening();
}


void loop()
{
  radio.write(&sendData, 2);
  delay(500);
  radio.write(&sendData2, 2);
  delay(500);
}

Receiver Code:

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


RF24 radio(9, 10); // CE, CSN


const byte address[6] = "00001";

uint16_t receivedData = 0;

#define ledPin 6

void setup()
{
  //Serial.begin(9600);
  
  pinMode(ledPin, OUTPUT);
  
  radio.begin();
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_HIGH);
  radio.startListening();
}


void loop()
{
  if (radio.available())
  {
    radio.read(&receivedData, 2);
  }
  //Serial.println(receivedData);

  if (receivedData == 0xFFFF) digitalWrite(ledPin, 1);
  if (receivedData == 0) digitalWrite(ledPin, 0);
  
}

The problem that I am having is that the data transfer is very intermittent once I bring the modules more than around 2 meters away. I fail to see how this could be a SPI issue since it works consistently at close distances.

I am not at all partial to these particular modules, and I would be willing to use any other type if it works within the contraints listed above. It also must be small and easily soldered to a PCB like with the SMD version of the NRF24.

Antenna orientation is important. For greatest distance, be sure the antenna planes are parallel to each other. They might be best both being vertical.

If you want to achieve a high packet rate, you should use a smaller fixed packet size,
or use dynamic payloads.

If transmission is critical, why is there no packet id,
and why does the sender not care about the success of the transmission?

Breadboards are only for tests, and don't work reliably.
It does not matter for a button or a LED, but SPI prefers less flimsy connections.

This is my first time doing anything with wireless communication so I don't know what any of that is. Could you provide some example code for packet ID and smaller fixed packet size?

Also, as far as antenna orientation, thats not something I'm going to be able to have any control over in the final design.

Yes, but I will not.

https://nrf24.github.io/RF24/classRF24.html

Added in
radio.setPayloadSize(2);

And now it is seemingly more reliable, about 5 meters through a wall. Any suggestions on tests to run to test reliability?

Also, I forgot to mention that the end result will have multiple receivers simultaneously receiving the same data from a single transmitter, so I'm having trouble imagining an acknowledge signal from the receiver in this scenario.

Then consider numbering your messages and transmitting each message, perhaps, 5 times. The receiver code must look at each message number and discard duplicate numbers. the 5 times is not magic and adjust that to fit your error rate.

In that case, it's unwise to use auto-ack.
Without the automatic retries, you will have to come up with a different scheme,
which will probably use a packet id.

Handshaking is quite hard in a multi target environment.

A reason for this behavior could be a congested channel,
you could try a different channel, that has more free air time.

Another reason could be lame 3.3V supply for the NRF.
Longer Packets need more power.

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